<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">
>From my understanding the biggest argument against this is the change in<br>
template-haskell?

</blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Not specifically.  My reservation is that</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><ul><li>it's an unforced change, <br></li><li>with no user demand</li><li>but some real user impact (you mention TH)</li><li>and some implementation cost (modest but very non-zero)</li><li>aiming to anticipate as-yet-unknown future requirements</li></ul></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><div>That's not a combination I like.  Pain now for possible (but uncertain) gain in the future.</div><div><br></div><div>I don't object to making types and terms behave similarly -- indeed I have invested lots of time working with Richard, Vlad, Andrei and others on proposals and MRs that move in this direction.  I'm just very unconvinced about <b>this </b>proposal.  <br></div><div><br></div><div>One minor point.  In patterns we allow this:</div><div style="margin-left:40px">f ((,) @Int @[a] x y) = ...</div><div>Here the type arguments are not type variables but full-blown types, and of course nested parens etc come "for free".  But this proposal concerns data type declarations in which we definitely don't want fulll-blown types. So it's more than a "terms and types should be the same" discussion.</div><div><br></div><div>Simon<br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Mar 2024 at 14:47, Malte Ott <<a href="mailto:malte.ott@maralorn.de">malte.ott@maralorn.de</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">From my understanding the biggest argument against this is the change in<br>
template-haskell?<br>
I am wondering how many users will actually be affected by that.<br>
TypeAbstractions are quite recent so I wouldn’t be surprised if not much<br>
template-haskell code is using the corresponding constructors.<br>
That might also be an argument to do this change now before the ecosystem has<br>
more time to settle on this.<br>
<br>
Simon, I am also curious. Why are you not convinced by the goal to make types<br>
and terms as similar as possible?<br>
<br>
Best<br>
Malte<br>
<br>
On 2024-03-22 14:23, Arnaud Spiwack wrote:<br>
> I'm happy to follow you on this. Especially since in the future that Vlad<br>
> hopes, where there'd be less difference between terms and types, this<br>
> particular feature may fall naturally, so it may be worth revisiting then<br>
> rather than paying the cost now.<br>
> <br>
> On Fri, 22 Mar 2024 at 09:53, Simon Peyton Jones <<br>
> <a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br>
> <br>
> > Do you worry about the implementation because of future maintenance costs?<br>
> >> Or because of the immediate cost of developing the feature?<br>
> ><br>
> ><br>
> > Mostly the former.  It's just a bit more un-forced complexity.<br>
> ><br>
> > As far as I can see, there aren't other objections to this design besides<br>
> >> the cost, right? There's no real possibility of an alternate, conflicting<br>
> >> design for data type arguments, is there?<br>
> >><br>
> ><br>
> > It's just Occam's razor.   No one is asking for this.  And I'm unconvinced<br>
> > by "future proofiing" because it's hard to correctly anticipate the future.<br>
> ><br>
> > Simon<br>
> ><br>
> > On Fri, 22 Mar 2024 at 08:13, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>><br>
> > wrote:<br>
> ><br>
> >> Simon,<br>
> >><br>
> >> Do you worry about the implementation because of future maintenance<br>
> >> costs? Or because of the immediate cost of developing the feature?<br>
> >><br>
> >> As far as I can see, there aren't other objections to this design besides<br>
> >> the cost, right? There's no real possibility of an alternate, conflicting<br>
> >> design for data type arguments, is there?<br>
> >><br>
> >> On Thu, 21 Mar 2024 at 10:57, Simon Peyton Jones <<br>
> >> <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<br>
> >>> 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>
> >>><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>
> >>><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 redundant parens.<br>
> >>> The change is *not driven by user need*, but rather solely by<br>
> >>> *uniformity*: these same forms are 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 recursive data<br>
> >>> types, etc.  Nothing hard, but more.<br>
> >>><br>
> >>> It's not a big deal either way.  Very few people expressed a view on<br>
> >>> GitHub.  My personal view is that the modest (albeit non-zero) gain does<br>
> >>> not justify the definite (albeit modest) pain. I would leave this until<br>
> >>> someone actually wants it.<br>
> >>><br>
> >>> Vlad argues for future-proofing, but my experience is that an eye to the<br>
> >>> future is sensible when you are making changes anyway; but making unforced<br>
> >>> changes solely for the future risks incurring pain now that, when the<br>
> >>> future comes, turns out to have been a poor investment.  We may have<br>
> >>> correctly anticipated, or we may not.<br>
> >>><br>
> >>> So my recommendation is to park this until we get a real user demand.<br>
> >>><br>
> >>> It's a perfectly sensible proposal, but adopting it is a judgement call.<br>
> >>> I'll leave a week for committee responses, and then we can just vote.<br>
> >>><br>
> >>> Simon<br>
> >>><br>
> >>> 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>
> >>><br>
> >>>> 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>
> >>>><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>
> >>><br>
> >><br>
> >><br>
> >> --<br>
> >> Arnaud Spiwack<br>
> >> Director, Research at <a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
> >><br>
> ><br>
> <br>
> -- <br>
> Arnaud Spiwack<br>
> Director, Research at <a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<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>
<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>