[m-dev.] User defined comparison and equality

Fergus Henderson fjh at cs.mu.OZ.AU
Thu Apr 10 15:42:54 AEST 2003

On 10-Apr-2003, Fergus Henderson <fjh at cs.mu.oz.au> wrote:
> On 10-Apr-2003, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> > If a type has user-defined comparison, are unifications in the
> > in = in is semidet mode implemented as calls to compare((=))?
> Only if the type does not have a user-defined equality.
> > Otherwise it seems to me that we can have A \= B but
> > compare((=), A, B).
> Yes, that is a correct interpretation of the current language reference
> manual.
> > The requirement that this not be the case is not listed as a
> > programmer obligation in the reference manual,
> Right -- currently there is no such obligation.
> Should there be?

After thinking about it a bit more, I think there should.

Otherwise the documented semantics for e.g. `list__sort'
don't make much sense; the semantics of list__sort(List0, List)
are documented as "List is List0 sorted", and `list__sort(in, out)' is
declared `det', but if comparison could return "=" in cases where
the two values don't unify (i.e. aren't equal according to the
user-defined equality relation), then there could be more than one
way of sorting the list, so we'd need to document whether the sort
was stable, etc.

compare/3 is primarily used for things like search trees, and in such
cases we really do want the equivalence relation induced by compare/3
to match the equality relation.

So I think we ought to change the language reference manual.

Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au

More information about the developers mailing list