Do you worry about the implementation because of future maintenance costs? Or because of the immediate cost of developing the feature?

Mostly the former. It's just a bit more un-forced complexity. As far as I can see, there aren't other objections to this design besides

the cost, right? There's no real possibility of an alternate, conflicting design for data type arguments, is there?

It's just Occam's razor. No one is asking for this. And I'm unconvinced by "future proofiing" because it's hard to correctly anticipate the future. Simon On Fri, 22 Mar 2024 at 08:13, Arnaud Spiwack wrote:

Simon,

Do you worry about the implementation because of future maintenance costs? Or because of the immediate cost of developing the feature?

As far as I can see, there aren't other objections to this design besides the cost, right? There's no real possibility of an alternate, conflicting design for data type arguments, is there?

On Thu, 21 Mar 2024 at 10:57, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2... .

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens. The change is *not driven by user need*, but rather solely by *uniformity*: these same forms are permitted in function definitions:

f :: forall (a :: k). blah f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.

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.

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.

So my recommendation is to park this until we get a real user demand.

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.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote:

...

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

From my understanding the biggest argument against this is the change in template-haskell? I am wondering how many users will actually be affected by that. TypeAbstractions are quite recent so I wouldn’t be surprised if not much template-haskell code is using the corresponding constructors. That might also be an argument to do this change now before the ecosystem has more time to settle on this.

Simon, I am also curious. Why are you not convinced by the goal to make types and terms as similar as possible? Best Malte On 2024-03-22 14:23, Arnaud Spiwack wrote:

I'm happy to follow you on this. Especially since in the future that Vlad hopes, where there'd be less difference between terms and types, this particular feature may fall naturally, so it may be worth revisiting then rather than paying the cost now.

On Fri, 22 Mar 2024 at 09:53, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Do you worry about the implementation because of future maintenance costs?

...

Or because of the immediate cost of developing the feature?

Mostly the former. It's just a bit more un-forced complexity.

As far as I can see, there aren't other objections to this design besides

...

the cost, right? There's no real possibility of an alternate, conflicting design for data type arguments, is there?

It's just Occam's razor. No one is asking for this. And I'm unconvinced by "future proofiing" because it's hard to correctly anticipate the future.

Simon

On Fri, 22 Mar 2024 at 08:13, Arnaud Spiwack wrote:

...

Simon,

Do you worry about the implementation because of future maintenance costs? Or because of the immediate cost of developing the feature?

As far as I can see, there aren't other objections to this design besides the cost, right? There's no real possibility of an alternate, conflicting design for data type arguments, is there?

On Thu, 21 Mar 2024 at 10:57, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2... .

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens. The change is *not driven by user need*, but rather solely by *uniformity*: these same forms are permitted in function definitions:

f :: forall (a :: k). blah f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.

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.

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.

So my recommendation is to park this until we get a real user demand.

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.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote:

...

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

The examples with redundant parentheses or duplicate kind signatures are not very compelling, indeed. But if I understand correctly, this proposal also permits using a wildcard binder for a visibly-quantified variable, like this: type T :: forall k (a :: k) -> Type data T _ _ where MkT :: T _ _ While this is not exactly an essential feature (one can work around it by giving unused names), it seems a more reasonable thing to want. I doubt the impact on TH will be very significant if we use pattern synonyms to support the old constructors. Adam On 22/03/2024 18:19, Simon Peyton Jones wrote:

>From my understanding the biggest argument against this is the change in template-haskell?

Not specifically.  My reservation is that

* it's an unforced change, * with no user demand * but some real user impact (you mention TH) * and some implementation cost (modest but very non-zero) * aiming to anticipate as-yet-unknown future requirements

That's not a combination I like.  Pain now for possible (but uncertain) gain in the future.

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 *this *proposal.

One minor point.  In patterns we allow this: f ((,) @Int @[a] x y) = ... 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.

Simon

On Fri, 22 Mar 2024 at 14:47, Malte Ott mailto:malte.ott@maralorn.de> wrote:

From my understanding the biggest argument against this is the change in template-haskell? I am wondering how many users will actually be affected by that. TypeAbstractions are quite recent so I wouldn’t be surprised if not much template-haskell code is using the corresponding constructors. That might also be an argument to do this change now before the ecosystem has more time to settle on this.

Simon, I am also curious. Why are you not convinced by the goal to make types and terms as similar as possible?

Best Malte

On 2024-03-22 14:23, Arnaud Spiwack wrote: > I'm happy to follow you on this. Especially since in the future that Vlad > hopes, where there'd be less difference between terms and types, this > particular feature may fall naturally, so it may be worth revisiting then > rather than paying the cost now. > > On Fri, 22 Mar 2024 at 09:53, Simon Peyton Jones < > simon.peytonjones@gmail.com mailto:simon.peytonjones@gmail.com> wrote: > > > Do you worry about the implementation because of future maintenance costs? > >> Or because of the immediate cost of developing the feature? > > > > > > Mostly the former.  It's just a bit more un-forced complexity. > > > > As far as I can see, there aren't other objections to this design besides > >> the cost, right? There's no real possibility of an alternate, conflicting > >> design for data type arguments, is there? > >> > > > > It's just Occam's razor.   No one is asking for this.  And I'm unconvinced > > by "future proofiing" because it's hard to correctly anticipate the future. > > > > Simon > > > > On Fri, 22 Mar 2024 at 08:13, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> > > wrote: > > > >> Simon, > >> > >> Do you worry about the implementation because of future maintenance > >> costs? Or because of the immediate cost of developing the feature? > >> > >> As far as I can see, there aren't other objections to this design besides > >> the cost, right? There's no real possibility of an alternate, conflicting > >> design for data type arguments, is there? > >> > >> On Thu, 21 Mar 2024 at 10:57, Simon Peyton Jones < > >> simon.peytonjones@gmail.com mailto:simon.peytonjones@gmail.com> wrote: > >> > >>> Dear Steering Committee > >>> > >>> Vlad proposes to amend proposal #425 > >>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de... https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...>to > >>> permit more wildcard binder forms in type declarations: > >>> https://github.com/ghc-proposals/ghc-proposals/pull/641 https://github.com/ghc-proposals/ghc-proposals/pull/641 > >>> > >>> You may find it easiest to look at the rich diff > >>> <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2... https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2...> > >>> . > >>> > >>> This is a pretty small generalisation which would allow > >>> > >>> data T (( (a :: k1) :: k2)) = ... > >>> > >>> in which the binder has multiple kind signatures and redundant parens. > >>> The change is *not driven by user need*, but rather solely by > >>> *uniformity*: these same forms are permitted in function definitions: > >>> > >>> f :: forall (a :: k). blah > >>> f @(((a::k1)::k2))) = ... > >>> > >>> is permitted. > >>> > >>> It imposes a change on Template Haskell syntax too. > >>> > >>> The implementation becomes a bit more complicated; more recursive data > >>> types, etc.  Nothing hard, but more. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> So my recommendation is to park this until we get a real user demand. > >>> > >>> 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. > >>> > >>> Simon > >>> > >>> On Thu, 21 Mar 2024 at 08:07, Adam Gundry mailto:adam@well-typed.com> wrote: > >>> > >>>> Dear Committee, > >>>> > >>>> Vlad proposes to amend proposal #425 to permit more wildcard binder > >>>> forms in type declarations: > >>>> > >>>> https://github.com/ghc-proposals/ghc-proposals/pull/641 https://github.com/ghc-proposals/ghc-proposals/pull/641 > >>>> > >>>> I'd like to nominate Simon PJ as the shepherd. > >>>> > >>>> Please guide us to a conclusion as outlined in > >>>> https://github.com/ghc-proposals/ghc-proposals#committee-process https://github.com/ghc-proposals/ghc-proposals#committee-process > >>>> > >>>> Cheers, > >>>> > >>>> Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

If forced to voice an opinion I am still slightly in favor of the proposal. Mainly because we have an implementor here who is motivated to implement this, thus the implementation cost seems less problematic. It's best to imagine that implementation is free. (If the implementation is too costly, no one will do it, and the entire proposal becomes moot.) What matters is the *maintenance *cost. In ten years time when all the current enthusiasts have moved on, our future selves will be working on the implementation. Here the additional complexity is not great. But neither is the benefit. Also let us remember the TH breakage. That is a real cost, imposed on our users. I was originally pretty much on the fence, leaning to reject. But the more we discuss it, the more convinced I become that we should park this until someone actually wants it. Simon On Sat, 30 Mar 2024 at 21:39, Malte Ott wrote:

On 22/03/2024 18:19, Simon Peyton Jones wrote:

...

>From my understanding the biggest argument against this is the change in template-haskell?

Not specifically. My reservation is that

* it's an unforced change, * with no user demand * but some real user impact (you mention TH) * and some implementation cost (modest but very non-zero) * aiming to anticipate as-yet-unknown future requirements

That's not a combination I like. Pain now for possible (but uncertain) gain in the future.

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 *this *proposal.

One minor point. In patterns we allow this: f ((,) @Int @[a] x y) = ... 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.

Simon

I see. I admit that I don’t feel expert enough to know if this design will turn out to be optimal.

If forced to voice an opinion I am still slightly in favor of the proposal. Mainly because we have an implementor here who is motivated to implement this, thus the implementation cost seems less problematic.

Best, Malte _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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. I am marginally in favour but could be talked out of it if I have misjudged the externalities of approval. Chris

On 27 Mar 2024, at 09:14, Simon Peyton Jones wrote:

Dear Simon, Chris, Eric, Moritz, Matthias

You have not responded to my email below.

I'll call a vote tomorrow, but I would love to hear your opinions as a member of the GHC SC.

Thanks

Simon

On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

...

Dear Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2....

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens. The change is not driven by user need, but rather solely by uniformity: these same forms are permitted in function definitions:

f :: forall (a :: k). blah f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.

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.

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.

So my recommendation is to park this until we get a real user demand.

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.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry mailto:adam@well-typed.com> wrote:

...

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

What is the impact on Template Haskell? Is it a breaking API change?

yes I think so -- we'd need to elaborate the TH data types. I don't like unforced breaking changes. That's why I advocate parking this. Simon On Thu, 28 Mar 2024 at 08:03, Simon Marlow wrote:

What is the impact on Template Haskell? Is it a breaking API change?

On Wed, 27 Mar 2024 at 09:15, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear Simon, Chris, Eric, Moritz, Matthias

You have not responded to my email below.

I'll call a vote tomorrow, but I would love to hear your opinions as a member of the GHC SC.

Thanks

Simon

On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2... .

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens. The change is *not driven by user need*, but rather solely by *uniformity*: these same forms are permitted in function definitions:

f :: forall (a :: k). blah f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.

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.

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.

So my recommendation is to park this until we get a real user demand.

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.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote:

...

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Can't we fairly easily use pattern synonyms to support the old constructors? That would avoid breaking any existing programs. (It would necessarily introduce some partial matches, so a library matching on the old constructors could fail if exposed to the new syntax, but by definition existing code won't be using the new syntax.) Old code would get incomplete pattern match warnings; and would fail outright if it analysed quoted code that used the new syntax. 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. Sebastian Graf (in another context) pointed me to YAGNI: https://martinfowler.com/bliki/Yagni.html The author puts it well. Simon On Thu, 28 Mar 2024 at 09:19, Adam Gundry wrote:

On 28/03/2024 08:40, Simon Peyton Jones wrote:

...

...

What is the impact on Template Haskell? Is it a breaking API change?

yes I think so -- we'd need to elaborate the TH data types.

Can't we fairly easily use pattern synonyms to support the old constructors? That would avoid breaking any existing programs. (It would necessarily introduce some partial matches, so a library matching on the old constructors could fail if exposed to the new syntax, but by definition existing code won't be using the new syntax.)

Adam

...

I don't like unforced breaking changes. That's why I advocate parking this.

Simon

On Thu, 28 Mar 2024 at 08:03, Simon Marlow mailto:marlowsd@gmail.com> wrote:

What is the impact on Template Haskell? Is it a breaking API change?

On Wed, 27 Mar 2024 at 09:15, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

Dear Simon, Chris, Eric, Moritz, Matthias

You have not responded to my email below.

I'll call a vote tomorrow, but I would love to hear your opinions as a member of the GHC SC.

Thanks

Simon

On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

Dear Steering Committee

Vlad proposes to amend proposal #425 < https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst>to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641 https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff < https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2... .

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens. The change is *not driven by user need*, but rather solely by *uniformity*: these same forms are permitted in function definitions:

f :: forall (a :: k). blah f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.

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.

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.

So my recommendation is to park this until we get a real user demand.

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.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry mailto:adam@well-typed.com> wrote:

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641 <https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in

https://github.com/ghc-proposals/ghc-proposals#committee-process < https://github.com/ghc-proposals/ghc-proposals#committee-process>

...

Cheers,

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On 2024-04-02 16:25, Simon Peyton Jones wrote:

Dear GHC Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

See my mail below. I recommend, fairly strongly, to park this until there is evidence of need.

- it's an unforced change, - with no user demand - but some real user impact (notably: it will break some TH users) - and some implementation cost (modest but very non-zero) - aiming to anticipate as-yet-unknown future requirements -- but YAGNI https://martinfowler.com/bliki/Yagni.html

I think it's time to vote. Please so before Monday morning. Thank you!

Since my arguments in favor of the proposal convinced you of this position I am fine with your recommendation, though mainly undecided. Best Malte

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. However, I'd like to point out two things. 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. 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. Thus the voting options should probably be: a) accept the amendment b) revise the amendment to avoid recursive/nested forms c) reject the amendment Vlad On Fri, Apr 19, 2024 at 12:15 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

Dear GHC Steering Committee

On 2 April I asked:

I think it's time to vote. Please so before Monday morning *[8 April]*.

...

Thank you!

*It is now 19 April, of the eight members of the committee only Malte has voted. *

Please please vote. Today! Use email and record your vote on the spreadsheet https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5.... Vlad you have a vote; since you are the proposer you may choose to abstain but I think it's up to you.

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.

Simon

On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

See my mail below. I recommend, fairly strongly, to park this until there is evidence of need.

- it's an unforced change, - with no user demand - but some real user impact (notably: it will break some TH users) - and some implementation cost (modest but very non-zero) - aiming to anticipate as-yet-unknown future requirements -- but YAGNI https://martinfowler.com/bliki/Yagni.html

I think it's time to vote. Please so before Monday morning. Thank you!

Simon

On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2... .

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens. The change is *not driven by user need*, but rather solely by *uniformity*: these same forms are permitted in function definitions:

f :: forall (a :: k). blah f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.

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.

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.

So my recommendation is to park this until we get a real user demand.

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.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote:

...

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

As per my earlier email, I have very little opinion about that, and I'm happy to follow Simon's recommendation. On Fri, 19 Apr 2024 at 13:28, Matthías Páll Gissurarson wrote:

I don’t seem to have write access to that sheet, but I’ve requested it now.

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.

So I vote accept (mildly)

/Matti Palli

On Fri, Apr 19, 2024 at 12:45 Vladislav Zavialov wrote:

...

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.

However, I'd like to point out two things.

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.

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.

Thus the voting options should probably be:

a) accept the amendment b) revise the amendment to avoid recursive/nested forms c) reject the amendment

Vlad

On Fri, Apr 19, 2024 at 12:15 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

On 2 April I asked:

I think it's time to vote. Please so before Monday morning *[8 April]*.

...

Thank you!

*It is now 19 April, of the eight members of the committee only Malte has voted. *

Please please vote. Today! Use email and record your vote on the spreadsheet https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5.... Vlad you have a vote; since you are the proposer you may choose to abstain but I think it's up to you.

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.

Simon

On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

See my mail below. I recommend, fairly strongly, to park this until there is evidence of need.

- it's an unforced change, - with no user demand - but some real user impact (notably: it will break some TH users) - and some implementation cost (modest but very non-zero) - aiming to anticipate as-yet-unknown future requirements -- but YAGNI https://martinfowler.com/bliki/Yagni.html

I think it's time to vote. Please so before Monday morning. Thank you!

Simon

On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2... .

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens. The change is *not driven by user need*, but rather solely by *uniformity*: these same forms are permitted in function definitions:

f :: forall (a :: k). blah f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.

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.

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.

So my recommendation is to park this until we get a real user demand.

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.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote:

...

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

That's exactly right. We are not choosing between change / no change, we are choosing between three possible changes: 1. Current proposal: only add support for @_ 2. Amendment sans recursion (if revised): add support for @_, @(_ :: k), _, and (_ :: k) 3. Amendment with recursion: add support for arbitrary combinations of @, _, ::, and ( ... ) It's going to be breaking in all three scenarios, unless we come up with a compatibility layer using pattern synonyms as Adam suggests (I have not investigated the feasibility of that). Vlad On Fri, Apr 19, 2024 at 5:59 PM Malte Ott wrote:

Thanks for the input Vlad. Regarding the breaking change to TH: Do I understand you correctly that the required changes from 425 have not landed in 9.10 and therefor accepting this proposal will not create anymore breakage, even between 9.10 and 9.12?

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.

Are you sure? We could, if we chose, just (continue to) not support "_" in TH. People generating TH code can always use a fresh variable instead. I'm still leaning towards "do nothing"; and if we don't want that, then "do the minimum" (ie the non-recursive form). We have so much complexity already, I don't want to add more. Simon PS sorry to be slow on this On Mon, 22 Apr 2024 at 21:26, Adam Gundry wrote:

I find Vlad's argument convincing: if we are already adding support for @_ then at the very least it's worth adding _ at the same time, and it seems to involve no more breakage or implementation cost than #425 unamended. So I vote to accept.

I'm on the fence as to whether to prefer the recursive version (more general and consistent with term syntax) or the non-recursive version (since it is simpler, and in practice the more general forms seem unlikely to be useful).

Adam

On 19/04/2024 17:17, Vladislav Zavialov wrote:

...

That's exactly right. We are not choosing between change / no change, we are choosing between three possible changes:

1. Current proposal: only add support for @_ 2. Amendment sans recursion (if revised): add support for @_, @(_ :: k), _, and (_ :: k) 3. Amendment with recursion: add support for arbitrary combinations of @, _, ::, and ( ... )

It's going to be breaking in all three scenarios, unless we come up with a compatibility layer using pattern synonyms as Adam suggests (I have not investigated the feasibility of that).

Vlad

On Fri, Apr 19, 2024 at 5:59 PM Malte Ott mailto:malte.ott@maralorn.de> wrote:

Thanks for the input Vlad. Regarding the breaking change to TH: Do I understand you correctly that the required changes from 425 have not landed in 9.10 and therefor accepting this proposal will not create anymore breakage, even between 9.10 and 9.12?

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

By "do nothing" do you mean not implementing @_ which is already in the proposal? Sorry to be ambiguous. I mean that the GHC Steering Committee does nothing -- i.e. leaves the spec as-is. So then it still has to be implemented. So the proposal is no good in its current form: it is rather inconsistent to have @_ but not _. Ah, I had not realised that. Thanks for pointing it out. I have responded on the discussion thread (this committee thread is too easily lost/missed.) Simon On Thu, 2 May 2024 at 14:35, Vladislav Zavialov wrote:

...

We could, if we chose, just (continue to) not support "_" in TH.

Do you mean supporting the feature in GHC but not in TH? E.g. if the programmer uses a TH quotation [d| type T @_ = ... |], the generated AST would actually be equivalent to [d| type T @_w1 = ... |] where _w1 is a fresh name? I think it'd be mostly fine, though it would be a lossy conversion, so if the user attempts to preprocess the TH AST before splicing it, they might be surprised to find that their wildcard is no longer a wildcard. In other words, the TH AST is not only produced but also sometimes consumed by user-written code, so I err on the side of representing things exactly rather than via an encoding.

I'm not thrilled about taking such shortcuts because they tend to bite back later, but yes, it could work.

...

I'm still leaning towards "do nothing"

By "do nothing" do you mean not implementing @_ which is already in the proposal? This would correspond to "do nothing" in implementation terms, but that'd be a conscious deviation from the spec. The intellectually honest thing to do in that case would be to update the spec to reflect this choice. So the proposal is no good in its current form: it is rather inconsistent to have @_ but not _. We need an amendment, but the question is which amendment: to add syntax or to remove it. Maybe your counterproposal is to remove @_ from the proposal? That would bring the spec in sync with the current impl.

Vlad

On Thu, May 2, 2024 at 3:05 PM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

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.

Are you sure? We could, if we chose, just (continue to) not support "_" in TH. People generating TH code can always use a fresh variable instead.

I'm still leaning towards "do nothing"; and if we don't want that, then "do the minimum" (ie the non-recursive form). We have so much complexity already, I don't want to add more.

Simon

PS sorry to be slow on this

On Mon, 22 Apr 2024 at 21:26, Adam Gundry wrote:

...

I find Vlad's argument convincing: if we are already adding support for @_ then at the very least it's worth adding _ at the same time, and it seems to involve no more breakage or implementation cost than #425 unamended. So I vote to accept.

I'm on the fence as to whether to prefer the recursive version (more general and consistent with term syntax) or the non-recursive version (since it is simpler, and in practice the more general forms seem unlikely to be useful).

Adam

On 19/04/2024 17:17, Vladislav Zavialov wrote:

...

That's exactly right. We are not choosing between change / no change, we are choosing between three possible changes:

1. Current proposal: only add support for @_ 2. Amendment sans recursion (if revised): add support for @_, @(_ :: k), _, and (_ :: k) 3. Amendment with recursion: add support for arbitrary combinations of @, _, ::, and ( ... )

It's going to be breaking in all three scenarios, unless we come up with a compatibility layer using pattern synonyms as Adam suggests (I have not investigated the feasibility of that).

Vlad

On Fri, Apr 19, 2024 at 5:59 PM Malte Ott mailto:malte.ott@maralorn.de> wrote:

Thanks for the input Vlad. Regarding the breaking change to TH: Do I understand you correctly that the required changes from 425 have not landed in 9.10 and therefor accepting this proposal will not create anymore breakage, even between 9.10 and 9.12?

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I voted to park, as per Simon's recommendation (although if it comes up again I would be against unless it can be made a non-breaking change perhaps by using Adam's suggestion of pattern synonyms). Cheers Simon On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones wrote:

Dear GHC Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

See my mail below. I recommend, fairly strongly, to park this until there is evidence of need.

- it's an unforced change, - with no user demand - but some real user impact (notably: it will break some TH users) - and some implementation cost (modest but very non-zero) - aiming to anticipate as-yet-unknown future requirements -- but YAGNI https://martinfowler.com/bliki/Yagni.html

I think it's time to vote. Please so before Monday morning. Thank you!

Simon

On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2... .

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens. The change is *not driven by user need*, but rather solely by *uniformity*: these same forms are permitted in function definitions:

f :: forall (a :: k). blah f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.

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.

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.

So my recommendation is to park this until we get a real user demand.

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.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote:

...

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

This looks cleaner. No objections here. On Fri, 3 May 2024 at 23:06, Simon Peyton Jones wrote:

Dear Steering Committee

Vlad proposes to amend proposal #425

...

https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2...

We have since exchanged some email, and I invite you to look at my latest post on the ticket, namely:

https://github.com/ghc-proposals/ghc-proposals/pull/641#issuecomment-2091099...

In the light of these exchanges I'd like to modify my previous recommendation of "reject/park". I now propose:

- Add wildcards to *all* binders in type declarations, not just @_. - Allow kind annotations for wildcards

These changes just fill out the design of #425 in two obvious ways. In particular:

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

HoweverI propose that we reject

- Do all this recursively - Make changes to Template Haskell

There is no obvious user need for data T2 @((k::Nat)::Nat) = MkT2 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.

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.

Perhaps we might enhance TH as part of a subsequent, bigger upheaval of TH syntax. But not now.

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.

If you want to object to this proposal, please do so by the end of Weds 8th May. Thanks!

Simon

Simon

On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2... .

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens. The change is *not driven by user need*, but rather solely by *uniformity*: these same forms are permitted in function definitions:

f :: forall (a :: k). blah f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.

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.

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.

So my recommendation is to park this until we get a real user demand.

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.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote:

...

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- -- Matthías Páll Gissurarson http://mpg.is/

Sounds good to me. On Sat, 4 May 2024 at 06:17, Chris Dornan wrote:

Thanks Simon,

This makes complete sense. I agree with you on minimising unnecessary TH churn and avoiding unnecessary complexity.

Chris

On 3 May 2024, at 22:06, Simon Peyton Jones wrote:

Dear Steering Committee

Vlad proposes to amend proposal #425

...

https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2...

We have since exchanged some email, and I invite you to look at my latest post on the ticket, namely:

https://github.com/ghc-proposals/ghc-proposals/pull/641#issuecomment-2091099...

In the light of these exchanges I'd like to modify my previous recommendation of "reject/park". I now propose:

- Add wildcards to *all* binders in type declarations, not just @_. - Allow kind annotations for wildcards

These changes just fill out the design of #425 in two obvious ways. In particular:

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

HoweverI propose that we reject

- Do all this recursively - Make changes to Template Haskell

There is no obvious user need for data T2 @((k::Nat)::Nat) = MkT2 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.

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.

Perhaps we might enhance TH as part of a subsequent, bigger upheaval of TH syntax. But not now.

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.

If you want to object to this proposal, please do so by the end of Weds 8th May. Thanks!

Simon

Simon

On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear Steering Committee

Vlad proposes to amend proposal #425 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-de...to permit more wildcard binder forms in type declarations: https://github.com/ghc-proposals/ghc-proposals/pull/641

You may find it easiest to look at the rich diff https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2... .

This is a pretty small generalisation which would allow

data T (( (a :: k1) :: k2)) = ...

in which the binder has multiple kind signatures and redundant parens. The change is *not driven by user need*, but rather solely by *uniformity*: these same forms are permitted in function definitions:

f :: forall (a :: k). blah f @(((a::k1)::k2))) = ...

is permitted.

It imposes a change on Template Haskell syntax too.

The implementation becomes a bit more complicated; more recursive data types, etc. Nothing hard, but more.

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.

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.

So my recommendation is to park this until we get a real user demand.

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.

Simon

On Thu, 21 Mar 2024 at 08:07, Adam Gundry wrote:

...

Dear Committee,

Vlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:

https://github.com/ghc-proposals/ghc-proposals/pull/641

I'd like to nominate Simon PJ as the shepherd.

Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process

Cheers,

Adam

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.