[ghc-steering-committee] a plea against ScopedTypeVariables

[Iavor Diatchki]

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 <trupill at gmail.com>
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 (<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
>>
> _______________________________________________
> 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/9a67702f/attachment-0001.html>