Lexically scoped type variables
simonpj at microsoft.com
Mon Feb 6 08:18:44 EST 2006
I took a look. Here's a typical example:
newVariableListFromSet :: Ord a => VariableSetSource a -> VariableList a
newVariableListFromSet (variableSetSource :: VariableSetSource a) =
attachListOp parallelX (listDrawer :: ListDrawer a pos) =
(posRegistry :: Registry a pos) <- newRegistry
groupingCount <- newIORef 0
updateFn :: VariableSetUpdate a -> IO ()
updateFn (AddElement a) =
To fix this you'd need to
a) Add a 'forall a.' to the sig for newVariableListFromSet. That brings
'a' into scope in the defn of the function. (Arguably, the *implicit*
foralls should be in scope too; I'd be interested in what you think.)
b) Add a type signature for attachListOp, beginning with forall pos.
The main thing we're creeping towards is making it clear where scoped
type variables are quantified. For example, is attachListOp polymorphic
in 'pos'? We are thinking about allowing you to bind the polymorphic
type variables of a function in patterns *on the left* of the '='. That
would make you happy, I think.
| -----Original Message-----
| From: Christian Maeder [mailto:maeder at tzi.de]
| Sent: 02 February 2006 17:19
| To: Simon Peyton-Jones; GHC Users Mailing List
| Subject: Re: Lexically scoped type variables
| > | Simon Peyton-Jones wrote:
| > | > I'm very interested to know whether you like it or hate it.
| > | > In the latter case, I'd also like to know whether you also
| > | > have programs that will be broken by the change.
| > |
| > | I don't use GADTs yet and I assume this change will not
| > | break our code, but let me/us know which compiler we should use
| > testing.
| I've installed now ghc-6.5.20060201 and I get quite a few errors of
| A pattern type signature cannot bind scoped type variables `s'
| unless the pattern has a rigid type context
| (and these are not always easy to fix in unknown non-haskell98 code by
| adding a "forall" and/or omitting the pattern type signatures)
| You may try to translate the attached sources by:
| ghc --make -cpp -fallow-undecidable-instances -fglasgow-exts
| (and tell me how I should fix this)
More information about the Glasgow-haskell-users