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

Sat May 4 04:17:06 UTC 2024

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 <simon.peytonjones at 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
> You may find it easiest to look at the rich diff <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>
> 
> 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-2091099038
> 
> 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 at gmail.com <mailto:simon.peytonjones at 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
>> 
>> You may find it easiest to look at the rich diff <https://github.com/ghc-proposals/ghc-proposals/pull/641/files?short_path=cb2a762#diff-cb2a762676d938436a07317bbd007570b5efdfa00b40763b897ee920694bcbb5>.
>> 
>> 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 <adam at well-typed.com <mailto:adam at 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 at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240504/0509b9e1/attachment-0001.html>