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