[ghc-steering-committee] a plea against ScopedTypeVariables

[Alejandro Serrano Mena]

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 (<arnaud.spiwack at tweag.io>)
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 <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
>>
> _______________________________________________
> 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/7a56c5bf/attachment-0001.html>