proposal: user-defined equality predicates

[Fergus Henderson]

Zoltan Somogyi <zs at cs.mu.OZ.AU> writes:

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

Quite easily.  For example, `some_module__bar' may be declared as

	:- pred some_module__bar(t1:in, t2::out) is det.
					    ^^^

and `t2' may be implemented as a non-canonical type.

Peter Schachte and I said "implied mode", but from your answers I think
you have this confused with "partially instantiated mode"...

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

Sure.

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

Yes, that assumption is correct.  I thought you were arguing against
the proposed extension.  Peter wrote

>> Why should implied modes of such [non-canonical] types be disallowed?  It
>> makes the language quirky. 

and you replied

>Implied modes should only be required in code that deals with the
>representation of the type.

which seemed to suggest that perhaps they _should_ be disallowed.

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