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

[Fergus Henderson]

Zoltan Somogyi, you wrote:
> 
> > 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. 
> 
> Implied modes should only be required in code that deals with the
> representation of the type.

But the problem is that you may be using implied modes without
even realizing it.  Code such as

	:- pred foo(t1::in, t2::in).
	foo(X, Y) :- some_module__bar(X, Y).

may be buggy, if it happens to be a call to an implied mode
for a non-canonical type.  Whether or not `t2' is implemented
as a non-canonical type is really an implementation detail of `t2
that the user of `t2' shouldn't have to worry about.
And whether or not `some_module__bar' is declared as

	:- pred some_module_bar(t1, t2).
	:- mode some_module_bar(in, in).
	:- mode some_module_bar(in, out).

or just as

	:- pred some_module_bar(t1, t2).
	:- mode some_module_bar(in, in).

is another thing that the user should not really have to worry about.

> I don't see *any* good reason for the
> representation of a type with a non-standard equality predicate
> to be exported from its defining module.

Agreed.

> I am even very doubtful
> about whether the code in the defining module needs implied modes of =
> for such types.

You never _need_ implied modes, you can always explicitly call the
equality predicate for the type.  But suppose for example that you
have a program written using sets represented as sorted lists,
and you want to change it to use say red-black trees.  How are you going
to find all the calls to =/2 in (in, in) mode on sets, so that you
can change them to instead call set__equal?
Remember that these calls may be hidden inside polymorphic
predicates such as list__append, or may be implicit in calls
to implied modes.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.