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

Fri Apr 19 10:45:48 UTC 2024

I don't think I have a vote, as my term has ended. Even if I had one, I'd
abstain because it is my amendment.

However, I'd like to point out two things.

1. If the proposed amendment is rejected, we /still/ have to change
template-haskell to implement 425 in its current form. The specification
allows invisible wildcards `@_`, which can't be represented in
template-haskell at the moment. So I'd like to ask voting members to take
that into consideration: this is not an "unforced change" because there is
a change coming either way.

2. Simon argues against a new recursive data type in the AST. OK, I can see
the problem, but please don't forget about non-recursive forms `type T _ =
rhs` and `type T (_ :: k) = rhs`. Even if there is no user demand for
nested forms like `type T ((_ :: k1) :: k2) = rhs`, flat wildcard binders
are a less intrusive addition and I've personally wanted them several
times. So if the problem is recursion, please consider sending the
amendment for revision instead of rejecting it.

Thus the voting options should probably be:

a) accept the amendment
b) revise the amendment to avoid recursive/nested forms
c) reject the amendment

Vlad

On Fri, Apr 19, 2024 at 12:15 PM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC Steering Committee
>
> On 2 April I asked:
>
> I think it's time to vote.   Please so before Monday morning *[8 April]*.
>> Thank you!
>
>
>
> *It is now 19 April, of the eight members of the committee only Malte has
> voted. *
>
> Please please vote.  Today!   Use email and record your vote on the
> spreadsheet
> <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>.
> Vlad you have a vote; since you are the proposer you may choose to abstain
> but I think it's up to you.
>
> The proposal isn't a huge deal either way, but we owe it to the proposer
> and to ourselves to deal with our business in a timely way.
>
> Simon
>
> On Tue, 2 Apr 2024 at 17:25, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC 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
>>
>> See my mail below.   I recommend, fairly strongly, to park this until
>> there is evidence of need.
>>
>>    - it's an unforced change,
>>    - with no user demand
>>    - but some real user impact (notably: it will break some TH users)
>>    - and some implementation cost (modest but very non-zero)
>>    - aiming to anticipate as-yet-unknown future requirements -- but YAGNI
>>    <https://martinfowler.com/bliki/Yagni.html>
>>
>> I think it's time to vote.   Please so before Monday morning.  Thank you!
>>
>> 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/20240419/64adcd70/attachment-0001.html>