<div dir="ltr"><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Can't we fairly easily use pattern synonyms to support the old <br>
constructors? That would avoid breaking any existing programs. (It would <br>
necessarily introduce some partial matches, so a library matching on the <br>
old constructors could fail if exposed to the new syntax, but by <br>
definition existing code won't be using the new syntax.)
</blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Old code would get incomplete pattern match warnings; and would fail outright if it analysed quoted code that used the new syntax.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">It's all just extra complexity! We have so many mission-critical things to do. I'm arguing against taking out precious time and attention to deal with a problem that no one is asking us to solve.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Sebastian Graf (in another context) pointed me to YAGNI: <a href="https://martinfowler.com/bliki/Yagni.html">https://martinfowler.com/bliki/Yagni.html</a> The author puts it well.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 28 Mar 2024 at 09:19, Adam Gundry <<a href="mailto:adam@well-typed.com">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">On 28/03/2024 08:40, Simon Peyton Jones wrote:<br>
> > What is the impact on Template Haskell? Is it a breaking API change?<br>
> <br>
> yes I think so -- we'd need to elaborate the TH data types.<br>
<br>
Can't we fairly easily use pattern synonyms to support the old <br>
constructors? That would avoid breaking any existing programs. (It would <br>
necessarily introduce some partial matches, so a library matching on the <br>
old constructors could fail if exposed to the new syntax, but by <br>
definition existing code won't be using the new syntax.)<br>
<br>
Adam<br>
<br>
<br>
> I don't like unforced breaking changes. That's why I advocate parking this.<br>
> <br>
> Simon<br>
> <br>
> On Thu, 28 Mar 2024 at 08:03, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a> <br>
> <mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>>> wrote:<br>
> <br>
> What is the impact on Template Haskell? Is it a breaking API change?<br>
> <br>
> On Wed, 27 Mar 2024 at 09:15, Simon Peyton Jones<br>
> <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a> <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>>><br>
> wrote:<br>
> <br>
> Dear Simon, Chris, Eric, Moritz, Matthias<br>
> <br>
> You have not responded to my email below.<br>
> <br>
> I'll call a vote tomorrow, but I would love to hear your<br>
> opinions as a member of the GHC SC.<br>
> <br>
> Thanks<br>
> <br>
> Simon<br>
> <br>
> On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones<br>
> <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
> <mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>>> wrote:<br>
> <br>
> Dear Steering Committee<br>
> <br>
> Vlad proposes to amend proposal #425<br>
> <<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst</a>>to permit more wildcard binder forms in type declarations:<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>
> <<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>
> You may find it easiest to look at the rich diff<br>
> <<a href="https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5</a>>.<br>
> <br>
> This is a pretty small generalisation which would allow<br>
> <br>
> data T (( (a :: k1) :: k2)) = ...<br>
> <br>
> in which the binder has multiple kind signatures and<br>
> redundant parens. The change is *not driven by user need*,<br>
> but rather solely by *uniformity*: these same forms are<br>
> permitted in function definitions:<br>
> <br>
> f :: forall (a :: k). blah<br>
> f @(((a::k1)::k2))) = ...<br>
> <br>
> is permitted.<br>
> <br>
> It imposes a change on Template Haskell syntax too.<br>
> <br>
> The implementation becomes a bit more complicated; more<br>
> recursive data types, etc. Nothing hard, but more.<br>
> <br>
> It's not a big deal either way. Very few people expressed a<br>
> view on GitHub. My personal view is that the modest (albeit<br>
> non-zero) gain does not justify the definite (albeit modest)<br>
> pain. I would leave this until someone actually wants it.<br>
> <br>
> Vlad argues for future-proofing, but my experience is that<br>
> an eye to the future is sensible when you are making changes<br>
> anyway; but making unforced changes solely for the future<br>
> risks incurring pain now that, when the future comes, turns<br>
> out to have been a poor investment. We may have correctly<br>
> anticipated, or we may not.<br>
> <br>
> So my recommendation is to park this until we get a real<br>
> user demand.<br>
> <br>
> It's a perfectly sensible proposal, but adopting it is a<br>
> judgement call. I'll leave a week for committee responses,<br>
> and then we can just vote.<br>
> <br>
> Simon<br>
> <br>
> On Thu, 21 Mar 2024 at 08:07, Adam Gundry<br>
> <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a> <mailto:<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>>> wrote:<br>
> <br>
> Dear Committee,<br>
> <br>
> Vlad proposes to amend proposal #425 to permit more<br>
> 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>
> <<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> <<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>
-- <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>
_______________________________________________<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>