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

[Adam Gundry]

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 <arnaud.spiwack at tweag.io 
> <mailto:arnaud.spiwack at 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
>     <reisenberg at janestreet.com <mailto:reisenberg at 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
>         <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at 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
>             <moritz.angermann at gmail.com
>             <mailto:moritz.angermann at 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
>                 <adam at well-typed.com <mailto:adam at 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