[ghc-steering-committee] a plea against ScopedTypeVariables

Simon Marlow marlowsd at gmail.com
Fri Dec 4 08:46:48 UTC 2020


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201204/fa70e7bb/attachment.html>


More information about the ghc-steering-committee mailing list