<div dir="ltr"><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Does this one have a purpose?

</blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Well, yes.   It allows people who want pattern signatures that do not bind to have pattern signatures that do not bind.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Given that it is easy to specify, and easy to implement, I'm inclined to give them their wishes.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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. <br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"></div><div style="font-family:tahoma,sans-serif" class="gmail_default">(If it was hard to implement something that would be a strike against choice; but that's not at issue here.)  <br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I don't think this particular issue is worth burning many cycles over :-).  Let's just accept and move on.<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 29 Jan 2024 at 09:36, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, 26 Jan 2024 at 21:14, Adam Gundry <<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would argue that we should be willing to remove (mis)features from <br>
future GHC20xx editions, and that (the PatternSignatureBinds component <br>
of) ScopedTypeVariables is potentially such a misfeature.<br></blockquote><div><br></div><div>I agree (in fact, I'd say that it's the whole point of language editions). Hence my question :-) .</div><div><br></div><div>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.</div><div><br></div><div>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?<br></div></div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>