Scoped type variables

Simon Peyton-Jones simonpj at
Mon Dec 20 04:22:15 EST 2004

| Some design choices are unclear, at least to me. First, the
| separation of body and signature. I am used to locally introduced
| identifiers being visible locally too (i.e. requiring minimal
| scrolling through a file). This would break, meaning that I have to
| know which identifier was used in the signature. Related to this, how
| does this work out for signatures of class members and their
| instances, often separated over different files? A change in a type
| variable in a signature in a class inside a library might then break
| my instance of that class. Or is this mechanism only meant for let
| bound values? 

My intention was that in an instance declaration, only the type
variables introduced in the head of the declaration (instance Eq a => Eq
[a] where...) would scope over the bodies.  The class declaration would
be irrelevant.

| The following then also might be admitted:
| 	f :: (forall a . a -> a) -> ...
|          v = f (\x -> x::a)

I'm suggesting *only* the outermost forall'd variables of the
definition. That's bad enough!   Nesting is overkill, and the scoping
rules would be complex to describe.

| Second, for a duplicate introduction of 'a' in:
| 	f :: [a] -> [a]
| 	f (x::a) = <body>
| Is the 'a' introduced in 'f (x::a)' shadowing the 'a' introduced in
| 'f :: [a] -> [a]'? If so, the separation of body and signature is
| slightly less of a problem because the 'a' introduced in the pattern
| will not create a 'duplicate identifier introduction' error message
| or a type mismatch (here between [a] and a).

The rule today in GHC is that a second use of a scoped type variable is
an *occurrence*.  Thus
	f = \(x::a) -> \(y::a) -> ..
the first 'a' binds the a, the second is an occurrence of it.   Yes,
it's a hack.  One could imagine requiring different syntax for the
binding occurrences, for example, but it's a really convenient one, and
hasn't given rise to difficulties that I know of.  So I'm proposing to
stick with it.


More information about the Glasgow-haskell-users mailing list