On Fri, Mar 07, 2008 at 08:07:57AM +0100, Tom Schrijvers wrote:
Am I correct in thinking this would have worked if it were an
associated type instead of an associated type synonym?
ie,
class C a where
data T a
val :: T a
Yes, you are. Associate data type constructors (as well as
I don't see how your example explains this particular error.
I agree Int cannot be generalized to (T Int) or (T Bool).
Generalized is not the right word here. In my example T Int, T Bool and
Int are all equivalent.
I see Stefan's local type signature is not (val :: a) like your (val ::Int)
Stefan Holdermans:
The problem is ambiguity. The type checker can't determine which
val function to use, i.e. which dictionary to pass to val.
I see. Still, maybe a type-error message in terms of good old
unresolved top-level overloading would be a bit more useful
here... ;-)
I agree
On Thu, Mar 6, 2008 at 3:57 PM, ChrisK [EMAIL PROTECTED] wrote:
Okay, I get the difference.
The T a annotation in val :: T a)and val :: T a does not help choose
the
C a dictionary.
But the val :: a- T a and val (undefined :: a) allows a to
successfully
choose the C a dictionary.
Am I correct in thinking this would have worked if it were an
associated type instead of an associated type synonym?
ie,
class C a where
data T a
val :: T a
Yes, you are. Associate data type constructors (as well as ordinary
algebraic data constructors) are injective. So we have: