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

[Zoltan Somogyi]

> 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.

How can this happen?

> 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.

If types with non-standard equality cannot be exported from their defining
module, then code in another module should only ever be able to cause two
kinds of unifications for values of that type: (in,out) which should always
mean assignment (no possibility of overriding), and (in,in). To help enforce
this, you may need to require that the defining module's interface not contain
any predicates or functions whose signatures refer to values of that type in
any partial instantiation state (i.e. not free or ground or their unique or
clobbered variants).

> 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.

I don't understand how this relates to what I wrote. I am assuming that
the base_type_info for the type with the non-standard equality will have
a reference to the user-provided in,in unification predicate (set__equal)
in the right slot.

Zoltan.