Hi What is the difference between data T0 f a = MkT0 a instance Eq (T0 f a) where ... and data T0 f a = MkT0 a instance Eq a => Eq (T0 f a) where ... I've only seen the "=>" operator used for declaring extended classes but never with class instances. By the way, what is the correct terms for the "=>" and the "->"? Cheers Paul
PR Stanley wrote:
Hi What is the difference between
data T0 f a = MkT0 a instance Eq (T0 f a) where ...
and
data T0 f a = MkT0 a instance Eq a => Eq (T0 f a) where ...
The second one says that "TO f a" is only an instance of "Eq" if "a" is, while the first says that "TO f a" is an instance regardless of the type of its arguments. You can regard an "instance" declaration as an inference rule for the type checker, with "=>" meaning "implies" (though I don't think its the answer to your other question about names).
Paul Johnson wrote:
You can regard an "instance" declaration as an inference rule for the type checker, with "=>" meaning "implies" (though I don't think its the answer to your other question about names).
"implies" might be a bad word, because the direction is backwards: Eq a => Ord a is clearly false if read that "Eq a implies Ord a". It is Ord a that implies Eq a. I just read it as "required for" myself. Dan
Hi, Am Dienstag, den 08.04.2008, 11:51 -0700 schrieb Dan Weston:
Paul Johnson wrote:
You can regard an "instance" declaration as an inference rule for the type checker, with "=>" meaning "implies" (though I don't think its the answer to your other question about names).
"implies" might be a bad word, because the direction is backwards:
Eq a => Ord a
is clearly false if read that "Eq a implies Ord a". It is Ord a that implies Eq a.
I just read it as "required for" myself.
I think both can be justified. Take
instance X a => Y a where ...
"X a" is required so that the instance declaration can be used. But also: Given this declaration, having an instance "X a" implies that you will also have an instance "Y a". But not not every type with "Y b" will also have "Y a". Or were you talking about constraints in the class declaration, which your choice of Eq and Ord suggests? Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org
Yes, sorry I should have read the post more carefully. I was talking specifically the use of => in class declarations, and this is a good example of how inconsistent the notation seems to me. It is in the class declaration that the arrow is backwards. (I imagine this decision was more syntactically motivated by the fact that <= is already the less-than-or-equal-to symbol, rather than intended semantic confusion?) class Necessary a => My a i.e. My a implies Necessary a instance Sufficient a => My a i.e. Sufficient a implies My a I pronounce the => in class declarations as "required for", and in instance definitions as "sufficient for". For me, the word "implies" is too tied in my brain to an arrow symbol to be useful to me in keeping the implications straight. Dan Joachim Breitner wrote:
Hi, Am Dienstag, den 08.04.2008, 11:51 -0700 schrieb Dan Weston:
Paul Johnson wrote:
You can regard an "instance" declaration as an inference rule for the type checker, with "=>" meaning "implies" (though I don't think its the answer to your other question about names). "implies" might be a bad word, because the direction is backwards:
Eq a => Ord a
is clearly false if read that "Eq a implies Ord a". It is Ord a that implies Eq a.
I just read it as "required for" myself.
I think both can be justified. Take
instance X a => Y a where ...
"X a" is required so that the instance declaration can be used.
But also:
Given this declaration, having an instance "X a" implies that you will also have an instance "Y a". But not not every type with "Y b" will also have "Y a".
Or were you talking about constraints in the class declaration, which your choice of Eq and Ord suggests?
Greetings, Joachim
------------------------------------------------------------------------
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
What is the difference between
data T0 f a = MkT0 a instance Eq (T0 f a) where ...
and
data T0 f a = MkT0 a instance Eq a => Eq (T0 f a) where ... The second one says that "TO f a" is only an instance of "Eq" if "a" is, while the first says that "TO f a" is an instance regardless of the type of its arguments.
More explanation please. :-) Much obliged, Paul
On Tue, Apr 8, 2008 at 11:05 PM, PR Stanley
What is the difference between
data T0 f a = MkT0 a instance Eq (T0 f a) where ...
and
data T0 f a = MkT0 a instance Eq a => Eq (T0 f a) where ...
The second one says that "TO f a" is only an instance of "Eq" if "a" is,
while the first says that "TO f a" is an instance regardless of the type of its arguments.
More explanation please. :-)
Well, it's similar with functions. If we try: foo :: a -> a -> Bool foo x y = x < y We'll get an error: the usage of `<` requires `a` to be in Ord class, which we write down as type signature: foo :: (Ord a) => a -> a -> Bool The similar effect is for type classes. Here:
instance Eq a => Eq (T0 f a) where ... We can see that we can compare elements of type `a` for equality. It's kind of saying: "if you give me an element of type `a`, and that type is in Eq class, I can tell you how to tell equality of elements of type T0 f a".
Regards Christopher Skrzętnicki
participants (6)
-
Ariel J. Birnbaum -
Dan Weston -
Joachim Breitner -
Krzysztof Skrzętnicki -
Paul Johnson -
PR Stanley