<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">I don’t have a strong opinion as I don’t do a whole lot of TLP, but consistency and uniformity are generally good, as long as we aren’t disruptive. Simon identifies some implementation complexity but I am not sure that implementation effort is so fungible as people tend to do the things they want to do anyway so we might as we’ll approve the proposal while being clear that it is not a priority — at least until some compelling use cases are brought to our attention.<div><br></div><div>I am marginally in favour but could be talked out of it if I have misjudged the externalities of approval.<br><div><br></div><div>Chris<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 27 Mar 2024, at 09:14, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Dear Simon, Chris, Eric, Moritz, Matthias</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">You have not responded to my email below.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I'll call a vote tomorrow, but I would love to hear your opinions as a member of the GHC SC.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</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 dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Dear Steering Committee</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
Vlad proposes to amend <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst" target="_blank">proposal #425 </a>to permit more wildcard binder forms in type declarations:<br><div style="margin-left:40px"> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/641" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/641</a></div><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">You may find it easiest to look at <a href="https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5" target="_blank">the rich diff</a>.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">This is a pretty small generalisation which would allow</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px">data T (( (a :: k1) :: k2)) = ...</div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">in which the binder has multiple kind signatures and redundant parens. The change is <b>not driven by user need</b>, but rather solely by <b>uniformity</b>: these same forms are permitted in function definitions:</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px">f :: forall (a :: k). blah</div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px">f @(((a::k1)::k2))) = ...</div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">is permitted.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">It imposes a change on Template Haskell syntax too.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">It's not a big deal either way. Very few people expressed a view on GitHub. My personal view is that the modest (albeit non-zero) gain does not justify the definite (albeit modest) pain. I would leave this until someone actually wants it.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Vlad argues for future-proofing, but my experience is that an eye to the future is sensible when you are making changes anyway; but making unforced changes solely for the future risks incurring pain now that, when the future comes, turns out to have been a poor investment. We may have correctly anticipated, or we may not.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">So my recommendation is to park this until we get a real user demand.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">It's a perfectly sensible proposal, but adopting it is a judgement call. I'll leave a week for committee responses, and then we can just vote.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 21 Mar 2024 at 08:07, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</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">Dear Committee,<br>
<br>
Vlad proposes to amend proposal #425 to permit more wildcard binder <br>
forms in type declarations:<br>
<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/641" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/641</a><br>
<br>
I'd like to nominate Simon PJ as the shepherd.<br>
<br>
Please guide us to a conclusion as outlined in<br>
<a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br>
<br>
Cheers,<br>
<br>
Adam<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>ghc-steering-committee mailing list<br>ghc-steering-committee@haskell.org<br>https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br></div></blockquote></div><br></div></div></body></html>