<html><body>
<div dir="ltr">Dear Committee,</div><div dir="ltr"><br></div><div dir="ltr">Richard has requested for us to consider the new version of this proposal. As opposed to the previous version, this one is only about reserving syntax for “modifiers”, which at the beginning would be used for things like linearity or matchability of arrows.</div><div dir="ltr"><br></div><div dir="ltr">I think this is a good proposal, and one which would save us from re-considering syntax for every possible extension (and if linearity appears before the arrow and matchability after it, where would a future dimension go?). Thus I keep recommending acceptance on this new incarnation.</div><div dir="ltr"><br></div><div dir="ltr">Regards,</div><div dir="ltr">Alejandro</div><div dir="ltr"><br><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 30 Nov 2020 at 20:52:26, Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</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 style="word-wrap:break-word;line-break:after-white-space" class="">To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable.<div class=""><br class=""></div><div class="">I've requested that the committee consider the updates in parallel with community feedback.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Richard<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena <<a href="mailto:trupill@gmail.com" class="">trupill@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">
<div dir="ltr" class="">
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" class=""><br class=""></div><div dir="ltr" class="">Regards,</div><div dir="ltr" class="">Alejandro</div><div dir="ltr" class=""><br class="">
<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" class="">eric@seidel.io</a>> wrote:<br class=""></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="">
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 class=""><br class="">On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote:<br class=""><blockquote type="cite" class=""> Hi,<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano<br class=""></blockquote><blockquote type="cite" class=""> Mena:<br class=""></blockquote><blockquote type="cite" class=""> > Dear all,<br class=""></blockquote><blockquote type="cite" class=""> > This proposal suggests adding syntax for a general notion of<br class=""></blockquote><blockquote type="cite" class=""> > modifiers, like the ones we’ve been talking about lately affecting<br class=""></blockquote><blockquote type="cite" class=""> > linearity or matchability of arrows. For example, if linear types and<br class=""></blockquote><blockquote type="cite" class=""> > unsaturated families are accepted as they stand, we would have `Int<br class=""></blockquote><blockquote type="cite" class=""> > #1 -> @U Bool` (or something like that), whereas with this proposal<br class=""></blockquote><blockquote type="cite" class=""> > we would have the more uniform `Int %1 %Unmatchable -> Bool`.<br class=""></blockquote><blockquote type="cite" class=""> > <br class=""></blockquote><blockquote type="cite" class=""> > Since the amount of modifiers is likely to increase in the future, I<br class=""></blockquote><blockquote type="cite" class=""> > think it’s a great idea to agree and reserve such syntax, instead of<br class=""></blockquote><blockquote type="cite" class=""> > coming up with different ways on each proposal. I thus recommend<br class=""></blockquote><blockquote type="cite" class=""> > acceptance of this proposal.<br class=""></blockquote><blockquote type="cite" class=""> > <br class=""></blockquote><blockquote type="cite" class=""> > The proposal itself:<br class=""></blockquote><blockquote type="cite" class=""> > (1) introduces syntax for modifiers in types and defines how to<br class=""></blockquote><blockquote type="cite" class=""> > type/kind check them,<br class=""></blockquote><blockquote type="cite" class=""> > (2) reserved such syntax for other uses in declarations and terms.<br class=""></blockquote><blockquote type="cite" class=""> > <br class=""></blockquote><blockquote type="cite" class=""> > I think the proposal still has its merits only with (1), even though<br class=""></blockquote><blockquote type="cite" class=""> > I lean towards accepting both parts of it.<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> I like the idea of reserving syntax here, but parts of the proposal<br class=""></blockquote><blockquote type="cite" class=""> smell a bit like premature generalization to me. Are we confident that<br class=""></blockquote><blockquote type="cite" class=""> all annotations we eventually would like to use with this feature can<br class=""></blockquote><blockquote type="cite" class=""> be expressed as types of a kind that is an instance of Modifier? Or<br class=""></blockquote><blockquote type="cite" class=""> should we reserve the ability to have annotations that don't fit that<br class=""></blockquote><blockquote type="cite" class=""> model?<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> Would we ever have annotation that may affect phases earlier than than<br class=""></blockquote><blockquote type="cite" class=""> typechecking? What if we want to use (%type e) and (%data e) to help<br class=""></blockquote><blockquote type="cite" class=""> with the SingleNamepace issues? Look like useful annotations to me, but<br class=""></blockquote><blockquote type="cite" class=""> I am not sure if they fit the framework proposed here.<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> The fact that we special-case %1 supports that.<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> The proposal explicitly has to state “No modifier polymorphism!”. But<br class=""></blockquote><blockquote type="cite" class=""> isn't that indication that using the type system to model the various<br class=""></blockquote><blockquote type="cite" class=""> modifiers might be the wrong tool?<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> I wonder if there is a way where the %(…) on it’s own only reserve<br class=""></blockquote><blockquote type="cite" class=""> syntax, and the various uses of that syntax can be disambiguated<br class=""></blockquote><blockquote type="cite" class=""> _statically_ based on the content of …. <br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> Not great syntax, because not concise, enough, but morally I’d feel<br class=""></blockquote><blockquote type="cite" class=""> more at ease with<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> Int %(multiplicity Many) -> Int<br class=""></blockquote><blockquote type="cite" class=""> Int %(multiplicity 1) -> Int<br class=""></blockquote><blockquote type="cite" class=""> Int %(multiplicity m) -> Int<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> where multiplicity is a modifier keyword, to express the existing<br class=""></blockquote><blockquote type="cite" class=""> features (including implicit generalization of m). Then we can extend<br class=""></blockquote><blockquote type="cite" class=""> this to<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> Int %oneShot -> Int<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> and<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> Int %(matchability M) -> Int<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> and maybe even<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> foo (%type [a]) -- where foo :: forall a -> ()<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> which is a modifier that <br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> So at the moment, I am inclined to reject this proposal, until I am<br class=""></blockquote><blockquote type="cite" class=""> convinced that we are not painting ourselves into a “all modifiers are<br class=""></blockquote><blockquote type="cite" class=""> types of special kinds and that’s all the syntax and behaviour we ever<br class=""></blockquote><blockquote type="cite" class=""> need” corner.<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> Minor detail: If we can annotate infix use of the (->) “type operator”,<br class=""></blockquote><blockquote type="cite" class=""> should we also be able to annotate other infix operators, i.e.<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) <br class=""></blockquote><blockquote type="cite" class=""> infixexp ::= lexp {modifier} qop infixexp<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> Cheers,<br class=""></blockquote><blockquote type="cite" class=""> Joachim<br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> -- <br class=""></blockquote><blockquote type="cite" class=""> Joachim Breitner<br class=""></blockquote><blockquote type="cite" class=""> <a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a><br class=""></blockquote><blockquote type="cite" class=""> <a href="http://www.joachim-breitner.de/" class="">http://www.joachim-breitner.de/</a><br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> <br class=""></blockquote><blockquote type="cite" class=""> _______________________________________________<br class=""></blockquote><blockquote type="cite" class=""> ghc-steering-committee mailing list<br class=""></blockquote><blockquote type="cite" class=""> <a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class=""></blockquote><blockquote type="cite" class=""> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class=""></blockquote><blockquote type="cite" class=""><br class=""></blockquote>_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class=""><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</div>
</blockquote>
</div>
</div>
</div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class=""><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 class=""></div></blockquote></div><br class=""></div></div>
</blockquote>
</div>
</div>
</body></html>