<div dir="ltr">As per my earlier email, I have very little opinion about that, and I'm happy to follow Simon's recommendation.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 19 Apr 2024 at 13:28, Matthías Páll Gissurarson <<a href="mailto:mpg@mpg.is">mpg@mpg.is</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><div dir="auto">I don’t seem to have write access to that sheet, but I’ve requested it now.</div><div dir="auto"><br></div><div dir="auto">I was on the fence here, and would have voted to park it until it was requested. But as int-index points out, a breaking change to TH is on the way anyway, and it would be good to improve the completeness at the same time.</div><div dir="auto"><br></div><div dir="auto">So I vote accept (mildly)</div><div dir="auto"><br clear="all"><div dir="auto"><div dir="ltr" class="gmail_signature">/Matti Palli</div></div></div></div><div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 19, 2024 at 12:45 Vladislav Zavialov <<a href="mailto:vlad.z.4096@gmail.com" target="_blank">vlad.z.4096@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">I don't think I have a vote, as my term has ended. Even if I had one, I'd abstain because it is my amendment.<div><br></div><div>However, I'd like to point out two things.</div><div><br></div><div>1. If the proposed amendment is rejected, we /still/ have to change template-haskell to implement 425 in its current form. The specification allows invisible wildcards `@_`, which can't be represented in template-haskell at the moment. So I'd like to ask voting members to take that into consideration: this is not an "unforced change" because there is a change coming either way.</div><div><br></div><div>2. Simon argues against a new recursive data type in the AST. OK, I can see the problem, but please don't forget about non-recursive forms `type T _ = rhs` and `type T (_ :: k) = rhs`. Even if there is no user demand for nested forms like `type T ((_ :: k1) :: k2) = rhs`, flat wildcard binders are a less intrusive addition and I've personally wanted them several times. So if the problem is recursion, please consider sending the amendment for revision instead of rejecting it.</div><div><br></div><div>Thus the voting options should probably be:</div><div><br></div><div>a) accept the amendment</div><div>b) revise the amendment to avoid recursive/nested forms</div><div>c) reject the amendment</div><div><br></div><div>Vlad</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 19, 2024 at 12:15 PM Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">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 dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">
<div class="gmail_default" style="font-family:tahoma,sans-serif">Dear GHC 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">On 2 April I asked:<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex;font-family:tahoma,sans-serif">I think it's time to vote. Please so before Monday morning <b style="font-family:tahoma,sans-serif">[8 April]</b>. Thank you!</blockquote><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif"><b style="font-family:tahoma,sans-serif">It is now 19 April, of the eight members of the committee only Malte has voted. <br></b></div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Please please<span style="font-family:tahoma,sans-serif;color:rgb(255,0,0)"> vote. Today! </span>Use email and record your vote on <a href="https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing" style="font-family:tahoma,sans-serif" target="_blank">the spreadsheet</a>. Vlad you have a vote; since you are the proposer you may choose to abstain but I think it's up to you.<br></div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">The proposal isn't a huge deal either way, but we owe it to the proposer and to ourselves to deal with our business in a timely way.<br></div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Simon <br></div>
</div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">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 style="font-family:tahoma,sans-serif">Dear GHC Steering Committee</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">
<span 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" style="font-family:tahoma,sans-serif" target="_blank">proposal #425 </a>to permit more wildcard binder forms in type declarations:<br><div style="margin-left:40px;font-family:tahoma,sans-serif"> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/641" rel="noreferrer" style="font-family:tahoma,sans-serif" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/641</a></div><div style="margin-left:40px;font-family:tahoma,sans-serif"><br></div>See my mail below. I recommend, fairly strongly, to park this until there is evidence of need.</span></div><div style="font-family:tahoma,sans-serif"><ul style="font-family:tahoma,sans-serif"><li style="font-family:tahoma,sans-serif">
<div style="font-family:tahoma,sans-serif">it's an unforced change, </div></li><li style="font-family:tahoma,sans-serif"><div style="font-family:tahoma,sans-serif">with no user demand</div></li><li style="font-family:tahoma,sans-serif"><div style="font-family:tahoma,sans-serif">but some real user impact (notably: it will break some TH users)</div></li><li style="font-family:tahoma,sans-serif"><div style="font-family:tahoma,sans-serif">and some implementation cost (modest but very non-zero)</div></li><li style="font-family:tahoma,sans-serif"><div style="font-family:tahoma,sans-serif">aiming to anticipate as-yet-unknown future requirements -- but <a href="https://martinfowler.com/bliki/Yagni.html" style="font-family:tahoma,sans-serif" target="_blank">YAGNI</a></div></li></ul><div style="font-family:tahoma,sans-serif">I think it's time to vote. Please so before Monday morning. Thank you!</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Simon<br></div></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" target="_blank">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 style="font-family:tahoma,sans-serif">Dear Steering Committee</div><div style="font-family:tahoma,sans-serif"><br></div><div 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" style="font-family:tahoma,sans-serif" target="_blank">proposal #425 </a>to permit more wildcard binder forms in type declarations:<br><div style="margin-left:40px;font-family:tahoma,sans-serif"> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/641" rel="noreferrer" style="font-family:tahoma,sans-serif" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/641</a></div><br></div><div 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" style="font-family:tahoma,sans-serif" target="_blank">the rich diff</a>.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">This is a pretty small generalisation which would allow</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif;margin-left:40px">data T (( (a :: k1) :: k2)) = ...</div><div style="font-family:tahoma,sans-serif;margin-left:40px"><br></div><div style="font-family:tahoma,sans-serif">in which the binder has multiple kind signatures and redundant parens. The change is <b style="font-family:tahoma,sans-serif">not driven by user need</b>, but rather solely by <b style="font-family:tahoma,sans-serif">uniformity</b>: these same forms are permitted in function definitions:</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif;margin-left:40px">f :: forall (a :: k). blah</div><div style="font-family:tahoma,sans-serif;margin-left:40px">f @(((a::k1)::k2))) = ...</div><div style="font-family:tahoma,sans-serif;margin-left:40px"><br></div><div style="font-family:tahoma,sans-serif">is permitted.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">It imposes a change on Template Haskell syntax too.</div><div style="font-family:tahoma,sans-serif"><br></div><div 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 style="font-family:tahoma,sans-serif"><br></div><div 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 style="font-family:tahoma,sans-serif"><br></div><div 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 style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">So my recommendation is to park this until we get a real user demand.</div><div style="font-family:tahoma,sans-serif"><br></div><div 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 style="font-family:tahoma,sans-serif"><br></div><div 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>
<a href="https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g" target="_blank">27 Old Gloucester Street, London WC1N 3AX, England</a><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>
</blockquote></div></div>
_______________________________________________<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>
_______________________________________________<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></div>
</div>
_______________________________________________<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><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>