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

[Simon Peyton Jones]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240402/9a1b2425/attachment.html>