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@tweag.io> wrote:
On Fri, 26 Jan 2024 at 21:14, Adam Gundry <adam@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@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee