this is an interesting discussion and i agree that in general instances
of Eq should be "equality", but what do people mean by "real equality"?
probably the most reasonable interpretation is some sort of
observational equivalance, i.e. if two things are equal we should always
be able to replace the one with the other. for a datatype that is not abstract
this basically forces the equality to be structural equality, which has prolems:
* if a datatype contains functions, structural equivalance is tricky
* every now and than i think the most common test i want to do is an equivalance,
and not equality (e.g. consider the implementation of join-lists)
so for datatypes that are not abstract it seems more reasonable to expect that
Eq will provide an equivalance relation rather than a real equality.
for abstract datatypes one can do better as the programmer could control what
observations are available to programmers. unfortunately, in Haskell it is a pain to work with those,
as we cannot use pattern matching anymore and programs become clunky.
so until we can think of better support for working with abstract datatypes, it seems
reasonbale to me to adopt daan's original design and have different datatstructures
for Bag and MultiSet (if these are commonly assumed to be the same, myabe they should have
some other names).
-iavor
Wolfgang Jeltsch wrote:
Am Mittwoch, 17. M�rz 2004 13:30 schrieb Ketil Malde:
[...]
Furthermore, having only an equivalence implies that there is aI've already said that I think Eq's (==) should be "structural
stronger equality below that cannot be also an instance of Eq.
equality", which I thought meant that there shouldn't be any
"deeper" equality.
I think, the name "structural equality" is misleading because it seems to imply that equivalent values have to have the same (internal) structure. If values a and b have different internal representations but are indistinguishable for the library user, than a == b should hold.
But I totally agree with you that == should mean equality and not anything different. And this is also what The Haskell Report says in � 6.3.1: "The Eq class provides equality (==) and inequality (/=) methods." So a lot of the MultiSet/Bag and the bias discussion can be avoided. DData can and should assume that the Eq methods mean exactly what they are supposed to mean: equality and inequality.
[...]
-kzm
Wolfgang
_______________________________________________
Libraries mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
