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, 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@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@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@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@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@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

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


--
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


--
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.