[ghc-steering-committee] a plea against ScopedTypeVariables

[Spiwack, Arnaud]

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 <marlowsd at gmail.com> 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 <rae at richarde.dev> 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-499572523,
>> 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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/696c490f/attachment.html>