Evan Laforge | 6 Aug 20:46 2013
Picon

ScopedTypeVariables

Occasionally I have to explicitly add a type annotation, either for
clarity or to help choose a typeclass instance.  Usually top-level
type annotations take care of this, but sometimes it's convenient to
only annotate a certain value, e.g. one argument of a lambda.

I've noticed that while vanilla haskell is happy to allow me to put
type annotations on variables where they are used (e.g. '\x -> f (x ::
T)'), if I put it on the variable where it is bound (e.g. '\(x :: T)
-> f x'), it wants me to turn on ScopedTypeVariables.

I think ScopedTypeVariables is a nice extension and I'm sure it comes
from a perfectly respectable family and all, but it feels like
annotations on arguments comes in as a side-effect.

Would it make sense to split it into a separate extension like
TypesOnArguments so I can more accurately express my deviation from
haskell2010 orthodoxy?  Or is there some deeper tie between scoped
type variables and annotations on arguments?

Now that I think of it, it seems inconsistent that 'x :: A -> B; x a =
...' is valid, but 'x = \(a :: A) -> (...) :: B' is not.  Doesn't the
former desugar to the latter?

And what about getting ScopedTypeVariables into haskell prime?  As far
as I know everyone loves it, or at least no one actually hates it :)
Dan Doel | 6 Aug 21:11 2013
Picon

Re: [Haskell-cafe] ScopedTypeVariables

This is already a separate extension: PatternSignatures. However, that extension is deprecated for some reason.


On Tue, Aug 6, 2013 at 2:46 PM, Evan Laforge <qdunkan <at> gmail.com> wrote:
Occasionally I have to explicitly add a type annotation, either for
clarity or to help choose a typeclass instance.  Usually top-level
type annotations take care of this, but sometimes it's convenient to
only annotate a certain value, e.g. one argument of a lambda.

I've noticed that while vanilla haskell is happy to allow me to put
type annotations on variables where they are used (e.g. '\x -> f (x ::
T)'), if I put it on the variable where it is bound (e.g. '\(x :: T)
-> f x'), it wants me to turn on ScopedTypeVariables.

I think ScopedTypeVariables is a nice extension and I'm sure it comes
from a perfectly respectable family and all, but it feels like
annotations on arguments comes in as a side-effect.

Would it make sense to split it into a separate extension like
TypesOnArguments so I can more accurately express my deviation from
haskell2010 orthodoxy?  Or is there some deeper tie between scoped
type variables and annotations on arguments?

Now that I think of it, it seems inconsistent that 'x :: A -> B; x a =
...' is valid, but 'x = \(a :: A) -> (...) :: B' is not.  Doesn't the
former desugar to the latter?

And what about getting ScopedTypeVariables into haskell prime?  As far
as I know everyone loves it, or at least no one actually hates it :)

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
John Wiegley | 6 Aug 21:13 2013

Re: ScopedTypeVariables

>>>>> Evan Laforge <qdunkan <at> gmail.com> writes:

> Would it make sense to split it into a separate extension like
> TypesOnArguments so I can more accurately express my deviation from
> haskell2010 orthodoxy?  Or is there some deeper tie between scoped
> type variables and annotations on arguments?

I've also wondered why I have to enable ScopedTypeVariables in those cases --
when I'm not turning it on to "scope" any type variables, but just to make
annotations possible in more places.

--

-- 
John Wiegley
FP Complete                         Haskell tools, training and consulting
http://fpcomplete.com               johnw on #haskell/irc.freenode.net

Gmane