Re: [ghc-steering-committee] Please review #641: Wildcard binders in type declarations

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 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

...

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

...

...

...

...

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

On 2024-03-22 14:23, Arnaud Spiwack wrote: parens. 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

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