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

26 Jan 2024

      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. Of course that 
could be quite a disruptive change, so for now I'm happy to see this 
proposal accepted so that we have at least the option of a more 
principled language design in the future.

Incidentally, I respectfully disagree with Richard's characterisation of 
this proposal as merely promoting a warning to be an extension. That 
would be true if PatternSignatureBinds/ScopedTypeVariables was a 
conservative extension, but it isn't - enabling the extension can change 
the meaning of existing programs [1].

Adam

[1] https://gist.github.com/adamgundry/5446f390ee84254c43a0425e821dc930

On 26/01/2024 19:30, Richard Eisenberg wrote:
...
Well, -XScopedTypeVariables is in GHC2021, and I think we're generally 
imagining increasing the size of this subset, not decreasing it. So the 
case you're wondering about (where we'd want one but not the other) 
seems unlikely to me.
On the other hand, if I generalize your question a bit to think about 
whether we'd want one but not the other in some language edition as in 
https://github.com/ghc-proposals/ghc-proposals/pull/628 
https://github.com/ghc-proposals/ghc-proposals/pull/628, then quite 
possibly. But if we go in that direction, the precise arrangement of 
language extensions matters not so much, because that view of the world 
removes language extensions from the set of things a user should be 
worrying about.
Richard
On Fri, Jan 26, 2024 at 11:10 AM Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote:
What I was asking was whether we imagined that `-XPatternSignatures`
    without the ability to bind would be in a future `GHC20xx`, but we
    don't think that `-XPatternSignature` with the ability to bind ought
    to. (and I was musing that the ability to bind would be replaced by
    `-XTypeAbstractions`).
On Fri, 26 Jan 2024 at 16:43, Richard Eisenberg
    mailto:reisenberg@janestreet.com> wrote:
I'm not sure I understand Arnaud's question here: this proposal
        removes the binding capability from -XPatternSignatures. I don't
        think there's an interaction with -XTypeAbstractions.
On Fri, Jan 26, 2024 at 3:04 AM Arnaud Spiwack
        mailto:arnaud.spiwack@tweag.io> wrote:
Do we envision, maybe, a future with `-XPatternSignature`,
            in a version that is incapable of binding and
            `-XTypeAbstractions`? If so, the split sounds like a
            reasonable move. Otherwise, the benefit of the split sounds
            rather slim, and it would need to be weighed against the
            costs and benefits on the implementation.
On Thu, 25 Jan 2024 at 07:07, Moritz Angermann
            mailto:moritz.angermann@gmail.com> wrote:
As this is guarded behind a language extension and as
                such should not impact any existing code. I'm happy to
                see this change.
On Thu, 25 Jan 2024 at 04:43, Adam Gundry
                mailto:adam@well-typed.com> wrote:
I'm also happily in favour, for the reason Joachim
                    articulates.
Adam
On 24/01/2024 18:24, Joachim Breitner wrote:
                     > Hi,
                     >
                     > Am Mittwoch, dem 24.01.2024 um 17:32 +0000
                    schrieb Richard Eisenberg:
                     >> - Accepting will make at least one person (John)
                    happy. And I don't note anyone who would become
                    unhappy. More happy people is more better. So I
                    recommend acceptance. :)
                     >
                     > unless I am mistaken, this proposal will also
                    un-deprecated
                     > -XPatternSignatures, and give it the semantics I
                    asked for in #119:
                     > allow me to write
                     >
                     >     foo :: Monad m => m Int
                     >     foo = do
                     >       list :: String <- return ""
                     >       return $ length list
                     >
                     > without treading into type variable territory,
                    having to turn on
                     > ScopedTypeVariables or anything like that. Finally!
                     >
                     >
                     > So it also makes me a bit happy; in favor.
                     >
                     > Cheers,
                     > Joachim
                     >
                     >
-- 
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