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

Fri Apr 19 12:40:13 UTC 2024

As per my earlier email, I have very little opinion about that, and I'm
happy to follow Simon's recommendation.

On Fri, 19 Apr 2024 at 13:28, Matthías Páll Gissurarson <mpg at mpg.is> wrote:

> I don’t seem to have write access to that sheet, but I’ve requested it now.
>
> I was on the fence here, and would have voted to park it until it was
> requested. But as int-index points out, a breaking change to TH is on the
> way anyway, and it would be good to improve the completeness at the same
> time.
>
> So I vote accept (mildly)
>
> /Matti Palli
>
>
> On Fri, Apr 19, 2024 at 12:45 Vladislav Zavialov <vlad.z.4096 at gmail.com>
> wrote:
>
>> 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
>>>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>>>> _______________________________________________
>>>>>> 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
>>
> _______________________________________________
> 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/20240419/73f09d17/attachment.html>