Although I have not yet submitted my votes yet, I do plan to vote for including ScopedTypeVariables, even though I also have some issues with it. Richard complains that `forall` brings type variables into scope at the term-level; I'm annoyed that I have to write the `forall` in the first place, I'd prefer to have all type variables brought into scope. But these quibbles don't matter. ScopedTypeVariables is a supremely useful extension even in its current state, and we should enable it. If we come up with a different, better design for ScopedTypeVariables in the future, we can 1. give it a new name 2. in GHC202X replace ScopedTypeVariables with the new extension 3. (slowly) deprecate ScopedTypeVariables Note that step 2 is non-breaking because people have to opt into the new language standard, so it actually makes these kinds of changes easier. That's one of the major draws of the GHC20XX idea! On Thu, Dec 3, 2020, at 15:06, Alejandro Serrano Mena wrote:

Whereas I agree that ScopedTypeVariables may not be ideal in its current incarnation, I think we should include this one for a few reasons.

* It's used a lot, in fact it's one of the most popular extensions in the survey, while still being not that contentious. I think almost everybody enables it liberally.

* It doesn't do harm unless you add the explicit 'forall' in the type signatures.

* Right now, there's no other way to bring type variables into scope! It would be really weird if GHC2021 would have TypeApplications, but I need to enable an extension to refer to variables in scope.

El jue, 3 dic 2020 a las 17:48, Richard Eisenberg () escribió:

...

Hi all,

I'd like to make a small plea against ScopedTypeVariables.

* First off, I love (most of) ScopedTypeVariables, and enable it liberally. It is a safe extension.

* But I very much dislike the way it brings variables into scope from `forall`s. When I write

...

f :: forall a. a -> a f x = (x :: a)

I find it very odd that `a` is brought into scope in the body of f. Compare to

...

f :: (forall a. a -> a) f x = (x :: a)

where I have added parentheses to the type of f. Now `a` is not in scope in the body of f. That's bizarre.

* Note that type signatures and function definitions can be arbitrarily separated in a file. Some programmers indeed prefer to do this, so that type signatures can all be in one place, forming an interface to the file. (I've even seen header files, included via CPP!) I'm not necessarily advocating for that style, but I can't quite say it's absurd. Our ML friends do this reflexively.

* I'm hoping ScopedTypeVariables will lose this feature in the future. I've been meaning to propose such for some time. See https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-4995725..., which re-slices this cake.

Thus, given the potential for change in the future, and some drawbacks of the extension as it currently stands, I think we should not enable it by default, making change harder in the future.

Thanks, Richard _______________________________________________ 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

I'm still undecided about ScopedTypeVariables (my vote says: maybe), because there are a number of discussions about changing this or that part of the semantics. That being said: I always turn ScopedTypeVariables on. I'd _love_ for it to be the default. The syntax is quirky, but I don't mind adding explicit `forall`-s. Type signatures on patterns, I don't care much about: I use them rarely. But the ability to bind a variable from the type signature inside the term, this is a very essential feature. I'd be just as happy with `\@a`, though. I'm very much on the fence here. Though, this is just the first time around for GHCXXXX, we can afford to be more conservative than on the next rounds. So given that there are doubts around this extension, maybe it's best to leave it out. And have a more ernest discussion for the second round. On Fri, Dec 4, 2020 at 9:47 AM Simon Marlow wrote:

That is an infelicity, I agree. However, ScopedTypeVariables fills a massive hole in Haskell, namely the inability to give a type signature to a local function when the type involves type variables bound by an outer scope. It feels like a shame to leave that hole unfilled in GHC2021, yet I understand the concerns.

Cheers Simon

On Thu, 3 Dec 2020 at 16:48, Richard Eisenberg wrote:

...

Hi all,

I'd like to make a small plea against ScopedTypeVariables.

* First off, I love (most of) ScopedTypeVariables, and enable it liberally. It is a safe extension.

* But I very much dislike the way it brings variables into scope from `forall`s. When I write

...

f :: forall a. a -> a f x = (x :: a)

I find it very odd that `a` is brought into scope in the body of f. Compare to

...

f :: (forall a. a -> a) f x = (x :: a)

where I have added parentheses to the type of f. Now `a` is not in scope in the body of f. That's bizarre.

* Note that type signatures and function definitions can be arbitrarily separated in a file. Some programmers indeed prefer to do this, so that type signatures can all be in one place, forming an interface to the file. (I've even seen header files, included via CPP!) I'm not necessarily advocating for that style, but I can't quite say it's absurd. Our ML friends do this reflexively.

* I'm hoping ScopedTypeVariables will lose this feature in the future. I've been meaning to propose such for some time. See https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-4995725..., which re-slices this cake.

Thus, given the potential for change in the future, and some drawbacks of the extension as it currently stands, I think we should not enable it by default, making change harder in the future.

Thanks, Richard _______________________________________________ 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

I do think that ScopedTypeVariables are useful, but not so much unless you are doing fancy type level programming (e.g., GADTs, type families, etc). It is quite easy to do a lot of Haskell without them, so I'd be fine without them in the standard. On Fri, Dec 4, 2020 at 5:27 AM Alejandro Serrano Mena wrote:

I'll reiterate my main point: ScopedTypeVariables is a very useful extension, and one which a lot of people would like to see in the default set. I would be happy to see it removed in a next iteration of the GHC20XX if a better story comes along, but even if we nail the design now, we would need to wait a few years for it to stabilize before inclusion. In the meanwhile, everybody would be wondering why ScopedTypeVariable is not the default.

El vie, 4 dic 2020 a las 14:00, Spiwack, Arnaud () escribió:

...

I'm still undecided about ScopedTypeVariables (my vote says: maybe), because there are a number of discussions about changing this or that part of the semantics.

That being said: I always turn ScopedTypeVariables on. I'd _love_ for it to be the default. The syntax is quirky, but I don't mind adding explicit `forall`-s. Type signatures on patterns, I don't care much about: I use them rarely. But the ability to bind a variable from the type signature inside the term, this is a very essential feature. I'd be just as happy with `\@a`, though.

I'm very much on the fence here. Though, this is just the first time around for GHCXXXX, we can afford to be more conservative than on the next rounds. So given that there are doubts around this extension, maybe it's best to leave it out. And have a more ernest discussion for the second round.

On Fri, Dec 4, 2020 at 9:47 AM Simon Marlow wrote:

...

That is an infelicity, I agree. However, ScopedTypeVariables fills a massive hole in Haskell, namely the inability to give a type signature to a local function when the type involves type variables bound by an outer scope. It feels like a shame to leave that hole unfilled in GHC2021, yet I understand the concerns.

Cheers Simon

On Thu, 3 Dec 2020 at 16:48, Richard Eisenberg wrote:

...

Hi all,

I'd like to make a small plea against ScopedTypeVariables.

* First off, I love (most of) ScopedTypeVariables, and enable it liberally. It is a safe extension.

* But I very much dislike the way it brings variables into scope from `forall`s. When I write

...

f :: forall a. a -> a f x = (x :: a)

I find it very odd that `a` is brought into scope in the body of f. Compare to

...

f :: (forall a. a -> a) f x = (x :: a)

where I have added parentheses to the type of f. Now `a` is not in scope in the body of f. That's bizarre.

* Note that type signatures and function definitions can be arbitrarily separated in a file. Some programmers indeed prefer to do this, so that type signatures can all be in one place, forming an interface to the file. (I've even seen header files, included via CPP!) I'm not necessarily advocating for that style, but I can't quite say it's absurd. Our ML friends do this reflexively.

* I'm hoping ScopedTypeVariables will lose this feature in the future. I've been meaning to propose such for some time. See https://github.com/ghc-proposals/ghc-proposals/pull/238#issuecomment-4995725..., which re-slices this cake.

Thus, given the potential for change in the future, and some drawbacks of the extension as it currently stands, I think we should not enable it by default, making change harder in the future.

Thanks, Richard _______________________________________________ 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

_______________________________________________ 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