fun deps and constraints in data decls
Simon Peyton-Jones
simonpj@microsoft.com
Tue, 6 May 2003 15:42:13 +0100
Yes, I think you could argue that this is a bug in GHC.
The trouble is that the data constructor T is really quantified over 'b'
as well, but the data type is not
T :: forall a b. C a b =3D> a -> T a
GHC assumes that the data type is parameterised over the same type
variables as the constructor. I could fix it so that it does not have
this assumption, but I'm not keen to do so
a) it's not trivial
b) it only involves the context to a data constructor, an entirely=20
unnecessary feature that I consider to be a mistake in Haskell.=20
I'm reluctant to invest effort in it.
So for now, let's treat it as a won't -fix bug.
Simon
| -----Original Message-----
| From: haskell-admin@haskell.org [mailto:haskell-admin@haskell.org] On
Behalf Of Iavor Diatchki
| Sent: 05 May 2003 19:47
| To: Haskell Mailing List
| Subject: fun deps and constraints in data decls
|=20
| > module Test where
|=20
| Hello,
|=20
| Both GHC and Hugs report an error on the example bellow,
| which to me seems wrong. Is this a bug, or am I missing something?
|=20
| > class C a b | a -> b
| > newtype C a b =3D> T a =3D T a
| > t :: C a b =3D> a -> T a
| > t =3D T
|=20
| The error reported is that "b" is an undefined type variable.
| Since "a" determines "b" using the functional dependency,
| I was expecting the example to work. I expected the type
| of the data constructor "T" to be as the one given in the
| type signature for "t", as I though that constraints on
| data/newtype declarations simply were added to the constructors.
| Both of the implementations are happy if I simply comment out the
| constraint,
| so they do not consider the type signature for "t" to be malformed in
| any way.
|=20
| bye
| iavor
|=20
|=20
| _______________________________________________
| Haskell mailing list
| Haskell@haskell.org
| http://www.haskell.org/mailman/listinfo/haskell