The first is a bug, thank you very much. Fixed in the upcoming release. The second is not a bug: see inline comments below. Simon | -----Original Message----- | From: Dylan Thurston [mailto:dpt@math.harvard.edu] | Sent: 21 August 2001 06:17 | To: glasgow-haskell-users@haskell.org | Subject: Problems with scoped type variables and existential | data constructors | | | I've been getting some slightly strange behaviour from ghc | 5.00.2 using existential data constructors, and I wonder if | it's correct. | | The first is that I can't seem to use scoped type variables | when matching against an existential data constructor. That is, | | > data Exist = forall a. Exist a | > | > bottom (Exist (_ :: t)) = Exist (undefined :: t) | | gives me the error | | Inferred type is less polymorphic than expected | Quantified type variable `a' is unified with `t' | When checking a pattern that binds | In an equation for function `bottom': | bottom (Exist (_ :: t)) = Exist (undefined :: t) | | I can work around this, as follows: | | > bottom' (Exist x) = case x of {(_::t) -> Exist (undefined :: t)} | | but it is annoying. | | | The second case may have to do with context reduction. Consider | | > class Silly a b | > | > data Exist a = forall t. Silly a t => Exist t | > | > data Id x = Id x | > instance (Silly a b) => Silly a (Id b) | > | > applyId (Exist x) = Exist (Id x) | | This gives me | | /tmp/t.hs:8: | Could not deduce `Silly a1 t' from the context (Silly a t) | Probable fix: | Add `Silly a1 t' | to the the existential context of a data constructor | arising from use of `Exist' at /tmp/t.hs:8 | in the definition of function `applyId': Exist (Id x) The trouble is that Exist :: forall a, t. Silly a t => Exist t Now this is an ambigous type, (which GHC doesn't current report, something I will fix), unless there's a functional dependency from t->a. So the two calls to Exist in the LHS and RHS have different 'a's, and that's why you can't discharge one with theother. Simon