[Haskell] Re: DData revision /equivalence vs equality

[Iavor S. Diatchki]

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 at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries
>  
>