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

Mon May 13 12:49:05 UTC 2024

Sounds good to me.

On Sat, 4 May 2024 at 06:17, Chris Dornan <chris at chrisdornan.com> 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 <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> 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> 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
>>> 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
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240513/01589617/attachment.html>