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

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/