<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">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im"><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 #<span class="gmail-il">425</span> </a>to permit more wildcard binder forms in type declarations:</div></span><br><span class="gmail-im"><div class="gmail_default" style="font-family:tahoma,sans-serif"><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></div></span></blockquote><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote><div><br></div><div>We have since exchanged some email, and I invite you to look at my latest post on the ticket, namely:</div><div> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/641#issuecomment-2091099038">https://github.com/ghc-proposals/ghc-proposals/pull/641#issuecomment-2091099038</a> <br></div><div><br></div><div>In the light of these exchanges I'd like to modify my previous recommendation of "reject/park". I now propose:</div><div><ul><li>Add wildcards to <em>all</em> binders in type declarations, not just <code class="gmail-notranslate">@_</code>.</li><li>Allow kind annotations for wildcards</li></ul><div>These changes just fill out the design of #425 in two obvious ways. In particular:</div><div>
<pre class="gmail-notranslate" style="margin-left:40px"><code class="gmail-notranslate">data T1 @_ = MkT1 -- Allowed by #425
data T2 @(_::Nat) = MkT2 -- Not currently allowed by #425
data T3 _ = MkT3 -- Not currently allowed by #425
data T4 (_ :: Nat) = MkT4 -- Not currently allowed by #425</code></pre>
</div><div>HoweverI propose that we reject</div><div><ul><li>Do all this recursively</li><li>Make changes to Template Haskell</li></ul><div>There is no obvious user need for <br></div><div> <code class="gmail-notranslate">data T2 @((k::Nat)::Nat) = MkT2</code></div><div>New recursive structures just add (modest but palpable) complexity to the specification and to the implementation. It is a cost without (so far as I can see) a user need or tangible benefit.</div><div><br></div><div>As to Template Haskell, neither #425 nor the above enhancement forces us to make a change to TH. Currently binders in TH data type declarations cannot have wildcards. There is no pressing reason to introduce them: one can always use a type variable instead. And our General Rules ask us to avoid making breaking changes without a strong reason to do so.</div><div><br></div><div>Perhaps we might enhance TH as part of a subsequent, bigger upheaval of TH syntax. But not now.</div><div><br></div><div>None of this is a terribly big deal. Unless anyone objects strenuously I propose to make this our decision and move on. It's always possible to do more later if there is a user need.</div><div><br></div><div>If you want to object to this proposal, please do so by the end of Weds 8th May. Thanks!</div><div><br></div><div>Simon<br></div><div><br></div><div>Simon<br></div></div></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">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>