[m-rev.] for review: where safe_equality is ...

[Zoltan Somogyi]

On 13-May-2003, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> I don't understand the rationale for this change.
> If the hand-defined types are being replaced with foreign types,
> it should be impossible to write a unification which examines
> their representation, so no unifications of values of those
> types should be required to be in committed choice contexts.
> 
> Could you give an example of a type for which `safe_equality'
> would be necessary?

The thing that prompted me to do this change is that I changed type_desc
and type_ctor_desc in type_desc.m to foreign types. I then got a bunch of
errors in std_util, which contains

:- type type_desc == type_desc__type_desc.
:- type type_ctor_desc == type_desc__type_ctor_desc.

The automatically created unify preds for these types got errors
because the calls to the unify preds of the underlying types weren't
in committed choice contexts.

The issue isn't whether the type with the user-defined equality is a foreign
type or not, it is whether (the unify pred behaves as if) the type has a
single representation for each abstract value.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------