[m-dev.] Re: proposal: user-defined equality predicates

[Peter Schachte]

On Fri, 27 Jun 1997, Andrew Bromage wrote:

> > My rationale for wanting this is that non-canonical types don't work in
> > Mercury (or any other logic programming language I know of).
> 
> I understand why implementing sets as unordered lists and defining
> equality on them in a nice way is a good idea.  However I think that
> it is incorrect to overload =/2 in this way.

I guess this is where we differ.  To me, =/2 should mean "equal."  (Read
that sentence aloud.)  It would be unacceptable to everyone, I assume, if
every type was required to define its own equality predictate (and it
couldn't be called =/2).  So why should we require this of types whose
only sin is that the mapping from a term to its meaning is not injective
(one-to-one)?  Why should implied modes of such types be disallowed?  It
makes the language quirky. 

Clearly there is a problem with unification on such types.  It seems
better to me to provide implementors a way to fix the problem than to
provide implementors a way to protect their users from self-inflicted foot
wounds, which in turn is better than the current situation (shoes with
bullseyes painted on). 

Anyway, clinging to the unification-is-only-structural-equivalence view
has not really made sense since functions were added.


-Peter Schachte      URL:  http://www.cs.mu.oz.au/~pets/
pets at cs.mu.OZ.AU     PGP:  finger pets at 128.250.37.150 for key
    [A computer is] like an Old Testament god, with a lot of rules
    and no mercy.  -- Joseph Campbell