DData revision /equivalence vs equality
Iavor S. Diatchki
diatchki at cse.ogi.edu
Wed Mar 17 09:51:59 EST 2004
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
this basically forces the equality to be structural equality, which has
* 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
and not equality (e.g. consider the implementation of join-lists)
so for datatypes that are not abstract it seems more reasonable to
Eq will provide an equivalance relation rather than a real equality.
for abstract datatypes one can do better as the programmer could control
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
for Bag and MultiSet (if these are commonly assumed to be the same,
myabe they should have
some other names).
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
>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.
>Libraries mailing list
>Libraries at haskell.org
More information about the Libraries