<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="">Hi committee,<div class=""><br class=""></div><div class="">I re-recommend acceptance for this proposal.</div><div class=""><br class=""></div><div class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">The main payload of the proposal is to allow definitions like</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><blockquote type="cite" class="">data Proxy @k (a :: k) = Proxy<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">instead of today's</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><blockquote type="cite" class="">data Proxy (a :: k) = Proxy<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">which has no explicit binding site for k.</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);" class="">This new syntax solves a number of smallish syntax conundra, as very well outlined in the proposal.</span></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Along with this primary change, there is some cleanup of (loosely) related syntax:</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""> - a type synonym declaration is now required to mention all kind variables on its left-hand side (previously, you could introduce a kind variable only on the right in some circumstances)</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""> - arity inference for type synonyms and families with trailing invisible quantifiers is simplified (you've never written such a thing, I'm sure -- and yet GHC currently has special handling for this bit of esoterica)</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""> - a type family equation must now mention all kind variables on its left-hand side (just like the new rule for type synonyms)</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""> - a type family equation must now determine instantiation of all kind variables via the left-hand side patterns (this vastly increases readability and avoids some confusing behavior)</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">The cleanups can all break existing code. And so I </span></font><a href="https://discourse.haskell.org/t/feedback-requested-about-breakage-type-variable-binders-in-datatypes/4241" class="">posted on Discourse</a><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""> seeking community feedback. The feedback did not suggest this breakage would cause wide harm. And thus this re-recommendation of acceptance.</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Please let us know what you think. I will go on holiday after April 4, so I hope to accept this proposal then.</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class=""><br class=""></span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Thanks!</span></font></div><div class=""><font color="#000000" class=""><span style="caret-color: rgb(0, 0, 0);" class="">Richard<br class=""></span></font><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 25, 2021, at 3:24 AM, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" class="">arnaud.spiwack@tweag.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">My weak objections are no match for Simon's strong keenness :-) .</div><div class=""><br class=""></div><div class="">I should say that, egoistically, I'd also like 5,6,7 to happen. I was only expressing concerns about the price.<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 22, 2021 at 1:00 PM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" class="">simonpj@microsoft.com</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 lang="EN-GB" class="">
<div class=""><p class="MsoNormal"><span class="">I’m in strong support. This tidies up the design nicely.<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span class="">I am particularly keen on 5,6,7; indeed I wrote a whole proposal about it, which Vlad has #included here<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal" style="text-indent:36pt"><span class=""><a href="https://github.com/ghc-proposals/ghc-proposals/pull/386" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals/pull/386</a><u class=""></u><u class=""></u></span></p><p class="MsoNormal" style="text-indent:36pt"><span class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span class="">Simon<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span style="font-size:8pt" class="">PS: I am leaving Microsoft at the end of November 2021, at which point
<a href="mailto:simonpj@microsoft.com" target="_blank" class=""><span style="color:rgb(5,99,193)" class="">simonpj@microsoft.com</span></a> will cease to work. Use
<a href="mailto:simon.peytonjones@gmail.com" target="_blank" class=""><span style="color:rgb(5,99,193)" class="">simon.peytonjones@gmail.com</span></a> instead. (For now, it just forwards to <a href="mailto:simonpj@microsoft.com" target="_blank" class="">simonpj@microsoft.com</a>.)<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class=""><u class=""></u> <u class=""></u></span></p>
<div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0cm 0cm 0cm 4pt" class="">
<div class="">
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm" class=""><p class="MsoNormal"><b class=""><span lang="EN-US" class="">From:</span></b><span lang="EN-US" class=""> ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank" class="">ghc-steering-committee-bounces@haskell.org</a>>
<b class="">On Behalf Of </b>Spiwack, Arnaud<br class="">
<b class="">Sent:</b> 21 October 2021 08:03<br class="">
<b class="">To:</b> Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank" class="">rae@richarde.dev</a>><br class="">
<b class="">Cc:</b> ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a>><br class="">
<b class="">Subject:</b> Re: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept<u class=""></u><u class=""></u></span></p>
</div>
</div><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
<div class=""><p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
I'm generally in favour. But I'm not convinced that the secondary changes (points 4–7) are worth it. They are certainly better place than we are today, but are they worth breaking existing code for? Point 5–7 can probably be replaced by warnings. I don't know
about 4.<u class=""></u><u class=""></u></p>
</div><p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u class=""></u> <u class=""></u></p>
<div class="">
<div class=""><p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
On Tue, Oct 19, 2021 at 11:20 PM Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank" class="">rae@richarde.dev</a>> wrote:<u class=""></u><u class=""></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm" class=""><p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Hi all,<br class="">
<br class="">
I am the shepherd for proposal #425, <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F425&data=04%7C01%7Csimonpj%40microsoft.com%7C32604dcfdde74a09b92608d99460fef7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637703967362805934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=qZtG9DdB6krhuKGwEnKuL0bPZr%2FYBr1jgRLIS1tb%2B5s%3D&reserved=0" target="_blank" class="">
https://github.com/ghc-proposals/ghc-proposals/pull/425</a>, proposing to add invisible binders in type declarations.<br class="">
<br class="">
The main payload of the proposal is to allow definitions like<br class="">
<br class="">
> data Proxy @k (a :: k) = Proxy<br class="">
<br class="">
instead of today's<br class="">
<br class="">
> data Proxy (a :: k) = Proxy<br class="">
<br class="">
which has no explicit binding site for k.<br class="">
<br class="">
This new syntax solves a number of smallish syntax conundra, as very well outlined in the proposal.<br class="">
<br class="">
In addition, the proposal includes two small unrelated tweaks to the syntax of type family instances; these are points (6) and (7) in the proposal. Both changes will break some obscure (but still realistic, knowing Haskell) programs, but both fixes are backward
compatible.<br class="">
<br class="">
---<br class="">
<br class="">
I recommend acceptance. The proposal is motivated nicely (do check out the examples) and solves a real problem. The new syntax fits in with other similar features. The small cleanups to existing syntax will lead to better error messages.<br class="">
<br class="">
The one drawback, as I see it, is that this proposal includes point (5), which is a breaking change to the way type synonyms work. Right now, we can say<br class="">
<br class="">
> type P = (Proxy :: k -> Type)<br class="">
<br class="">
and GHC will infer P :: forall k. k -> Type. Under this proposal, you would have to write<br class="">
<br class="">
> type P @k = (Proxy :: k -> Type)<br class="">
<br class="">
bringing k into scope explicitly. The fix is not backward compatible, and so I think this proposal should come with a migration strategy, where we warn about the former version for some releases before banning it. (Continuing to support it is possible, but
it's very awkward to have a variable mentioned only in a synonym's right-hand side.)<br class="">
<br class="">
Sorry for the delay in producing this recommendation!<br class="">
Richard<br class="">
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7C32604dcfdde74a09b92608d99460fef7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637703967362815898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=PrFP%2BiICXUykrsrJFBKkKzD9i3bS9Jd4YNdbl6CDYp8%3D&reserved=0" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><u class=""></u><u class=""></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote></div>
</div></blockquote></div><br class=""></div></body></html>