<html><body>
<div dir="ltr">
After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state.</div><div dir="ltr"><br></div><div dir="ltr">Regards,</div><div dir="ltr">Alejandro</div><div dir="ltr"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 29 Nov 2020 at 23:12:44, Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself.<br><br>On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:<br><blockquote type="cite"> Hi,<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano<br></blockquote><blockquote type="cite"> Mena:<br></blockquote><blockquote type="cite"> > Dear all,<br></blockquote><blockquote type="cite"> > This proposal suggests adding syntax for a general notion of<br></blockquote><blockquote type="cite"> > modifiers, like the ones we’ve been talking about lately affecting<br></blockquote><blockquote type="cite"> > linearity or matchability of arrows. For example, if linear types and<br></blockquote><blockquote type="cite"> > unsaturated families are accepted as they stand, we would have `Int<br></blockquote><blockquote type="cite"> > #1 -> @U Bool` (or something like that), whereas with this proposal<br></blockquote><blockquote type="cite"> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.<br></blockquote><blockquote type="cite"> > <br></blockquote><blockquote type="cite"> > Since the amount of modifiers is likely to increase in the future, I<br></blockquote><blockquote type="cite"> > think it’s a great idea to agree and reserve such syntax, instead of<br></blockquote><blockquote type="cite"> > coming up with different ways on each proposal. I thus recommend<br></blockquote><blockquote type="cite"> > acceptance of this proposal.<br></blockquote><blockquote type="cite"> > <br></blockquote><blockquote type="cite"> > The proposal itself:<br></blockquote><blockquote type="cite"> > (1) introduces syntax for modifiers in types and defines how to<br></blockquote><blockquote type="cite"> > type/kind check them,<br></blockquote><blockquote type="cite"> > (2) reserved such syntax for other uses in declarations and terms.<br></blockquote><blockquote type="cite"> > <br></blockquote><blockquote type="cite"> > I think the proposal still has its merits only with (1), even though<br></blockquote><blockquote type="cite"> > I lean towards accepting both parts of it.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> I like the idea of reserving syntax here, but parts of the proposal<br></blockquote><blockquote type="cite"> smell a bit like premature generalization to me. Are we confident that<br></blockquote><blockquote type="cite"> all annotations we eventually would like to use with this feature can<br></blockquote><blockquote type="cite"> be expressed as types of a kind that is an instance of Modifier? Or<br></blockquote><blockquote type="cite"> should we reserve the ability to have annotations that don't fit that<br></blockquote><blockquote type="cite"> model?<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Would we ever have annotation that may affect phases earlier than than<br></blockquote><blockquote type="cite"> typechecking? What if we want to use (%type e) and (%data e) to help<br></blockquote><blockquote type="cite"> with the SingleNamepace issues? Look like useful annotations to me, but<br></blockquote><blockquote type="cite"> I am not sure if they fit the framework proposed here.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> The fact that we special-case %1 supports that.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> The proposal explicitly has to state “No modifier polymorphism!”. But<br></blockquote><blockquote type="cite"> isn't that indication that using the type system to model the various<br></blockquote><blockquote type="cite"> modifiers might be the wrong tool?<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> I wonder if there is a way where the %(…) on it’s own only reserve<br></blockquote><blockquote type="cite"> syntax, and the various uses of that syntax can be disambiguated<br></blockquote><blockquote type="cite"> _statically_ based on the content of …. <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Not great syntax, because not concise, enough, but morally I’d feel<br></blockquote><blockquote type="cite"> more at ease with<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Int %(multiplicity Many) -> Int<br></blockquote><blockquote type="cite"> Int %(multiplicity 1) -> Int<br></blockquote><blockquote type="cite"> Int %(multiplicity m) -> Int<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> where multiplicity is a modifier keyword, to express the existing<br></blockquote><blockquote type="cite"> features (including implicit generalization of m). Then we can extend<br></blockquote><blockquote type="cite"> this to<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Int %oneShot -> Int<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> and<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Int %(matchability M) -> Int<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> and maybe even<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> foo (%type [a]) -- where foo :: forall a -> ()<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> which is a modifier that <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> So at the moment, I am inclined to reject this proposal, until I am<br></blockquote><blockquote type="cite"> convinced that we are not painting ourselves into a “all modifiers are<br></blockquote><blockquote type="cite"> types of special kinds and that’s all the syntax and behaviour we ever<br></blockquote><blockquote type="cite"> need” corner.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Minor detail: If we can annotate infix use of the (->) “type operator”,<br></blockquote><blockquote type="cite"> should we also be able to annotate other infix operators, i.e.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) <br></blockquote><blockquote type="cite"> infixexp ::= lexp {modifier} qop infixexp<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Cheers,<br></blockquote><blockquote type="cite"> Joachim<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> -- <br></blockquote><blockquote type="cite"> Joachim Breitner<br></blockquote><blockquote type="cite"> <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a><br></blockquote><blockquote type="cite"> <a href="http://www.joachim-breitner.de/">http://www.joachim-breitner.de/</a><br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> _______________________________________________<br></blockquote><blockquote type="cite"> ghc-steering-committee mailing list<br></blockquote><blockquote type="cite"> <a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br></blockquote><blockquote type="cite"> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br></blockquote><blockquote type="cite"><br></blockquote>_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</div>
</blockquote>
</div>
</div>
</body></html>