hi , 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 a stronger equality below that cannot be also an instance of Eq.
I've already said that I think Eq's (==) should be "structural 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 Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries