<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; 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="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></body></html>