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

[Simon Peyton Jones]

> What is the impact on Template Haskell? Is it a breaking API change?

yes I think so -- we'd need to elaborate the TH data types.

I don't like unforced breaking changes. That's why I advocate parking this.

Simon

On Thu, 28 Mar 2024 at 08:03, Simon Marlow <marlowsd at gmail.com> wrote:

> What is the impact on Template Haskell? Is it a breaking API change?
>
> On Wed, 27 Mar 2024 at 09:15, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear Simon, Chris, Eric, Moritz, Matthias
>>
>> You have not responded to my email below.
>>
>> I'll call a vote tomorrow, but I would love to hear your opinions as a
>> member of the GHC SC.
>>
>> Thanks
>>
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240328/5a975df2/attachment.html>