[ghc-steering-committee] Proposal #608, -XPatternSignatureBinds. Rec: accept

[Simon Peyton Jones]

Does this one have a purpose?


Well, yes.   It allows people who want pattern signatures that do not bind
to have pattern signatures that do not bind.

Given that it is easy to specify, and easy to implement, I'm inclined to
give them their wishes.

Having lots of combinations be possible (for users who care to specify
them), as GHC has historically done, is fully compatible with language
editions that embody a particular set of choices.   I like language
editions, but I don't see them as a reason to restrict choice.

(If it was hard to implement something that would be a strike against
choice; but that's not at issue here.)

I don't think this particular issue is worth burning many cycles over :-).
Let's just accept and move on.

Simon

On Mon, 29 Jan 2024 at 09:36, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> On Fri, 26 Jan 2024 at 21:14, Adam Gundry <adam at well-typed.com> wrote:
>
>> I would argue that we should be willing to remove (mis)features from
>> future GHC20xx editions, and that (the PatternSignatureBinds component
>> of) ScopedTypeVariables is potentially such a misfeature.
>>
>
> I agree (in fact, I'd say that it's the whole point of language editions).
> Hence my question :-) .
>
> I don't, however, agree that we should make arguments on the grounds of
> the swiss-army-knife philosophy (“make it possible to customise GHC to
> everybody's desires”). I think that 2023 has been a convincing
> demonstration that this philosophy hasn't served us well, and has been
> counterproductive. Actually, I was under the impression that all the
> discourse about basing our stability guarantees on language editions was a
> definite adoption of the newer point of view. It does seem, though, that
> we're not yet in complete agreement there.
>
> I'm content to concede here, but you'll have noticed in my recent
> interventions that I'm increasingly prudent about entropy-increasing
> changes (I'm worried, I guess, about death by a thousand paper cuts). I'd
> rather changes that we accept have a purpose. Does this one have a purpose?
> _______________________________________________
> 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/20240129/f2fca094/attachment.html>