[m-dev.] user-defined equality on equivalence types

[Fergus Henderson]

On 02-Mar-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 02-Mar-2000, David Glen JEFFERY <dgj at cs.mu.OZ.AU> wrote:
> > `equivalent in all respects' is a property worth preserving, IMHO, and this
> > means that equality should also be equivalent.
> 
> I think that "equivalent in all respects" is a property worth preserving
> *only in some contexts*; in certain contexts, this property is already
> violated. In particular, when an exported abstract type is defined by an
> equivalence internal to its defining module, references to the abstract
> type in other modules should not be compatible with the type that the
> abstract type is equivalent to. If they were, the abstraction barrier
> would be meaningless.
> 
> The property that may be worth preserving is that equivalence types
> "are equivalent in all respects *in scopes where the equivalence type
> is visible*" (from the reference manual).

When intermodule optimization is enabled, the compiler makes
equivalence types visible (as `opt_imported') in scopes where they
would not otherwise be visible.  Any proposal which would
give things different semantics (rather than just different
legality) depending on whether something is visible or not
could make intermodule optimization much more difficult.

The use of ADTs defined as equivalence types also causes problems
for type classes.  There are several possible solutions
to that, but one of the better ones is deprecating ADTs defined
as equivalence types, in favour of no_tag types.
Note that another related point is that ADTs defined as equivalence
types will probably cause difficulty for a Java back-end, since Java does
not support equivalence types.

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