[ghc-steering-committee] a plea against ScopedTypeVariables

[Alejandro Serrano Mena]

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 (<rae at richarde.dev>)
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-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/846bc766/attachment.html>