Thanks Simon,_______________________________________________This makes complete sense. I agree with you on minimising unnecessary TH churn and avoiding unnecessary complexity.ChrisOn 3 May 2024, at 22:06, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:Dear Steering CommitteeVlad proposes to amend proposal #425 to permit more wildcard binder forms in type declarations:You may find it easiest to look at the rich diffWe have since exchanged some email, and I invite you to look at my latest post on the ticket, namely: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 #425HoweverI propose that we reject
- Do all this recursively
- Make changes to Template Haskell
There is no obvious user need fordata T2 @((k::Nat)::Nat) = MkT2New 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!SimonSimon_______________________________________________On Thu, 21 Mar 2024 at 09:56, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:Dear Steering CommitteeYou may find it easiest to look at the rich diff.This is a pretty small generalisation which would allowdata 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). blahf @(((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.SimonOn Thu, 21 Mar 2024 at 08:07, Adam Gundry <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
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