proposal: user-defined equality predicates
Fergus Henderson
fjh at hydra.cs.mu.oz.au
Thu Jun 26 20:16:49 AEST 1997
Hi,
I propose to extend Mercury to support user-defined equality predicates
for user-defined types. The following is a proposed new chapter for the
Mercury Language Reference Manual describing this feature. It is probably
a bit short on rationale and examples, but please let me know what you think.
-----------------------------------------------------------------------------
User-defined equality predicates
********************************
When defining abstract data types, often it is convenient to use a
non-canonical representation -- that is, one for which a single
abstract value may have more than one different possible concrete
representations. For example, you may wish to implement an abstract
type `set' by representing a set as an (unsorted) list.
:- module set_as_unsorted_list.
:- interface.
:- type set(T).
:- implementation.
:- import_module list.
:- type set(T) ---> set(list(T)).
In this example, the concrete representations `set([1,2])' and
`set([2,1])' would both represent the same abstract value, namely the
set containing the elements 1 and 2.
For types such as this, which do not have a canonical representation,
the standard definition of equality is the desired one; we want
equality on sets to mean equality of the abstract values, not equality
of their representations. To support such types, Mercury allows
programmers to specify a user-defined equality predicate for
user-defined types:
:- type set(T) ---> set(list(T))
where equality is set_equals.
Here `set_equals' is the name of a user-defined predicate that is used
for equality on the type `set(T)'. It could for example be defined in
terms of a `subset' predicate.
:- pred set_equals(set(T)::in, set(T)::in) is semidet.
set_equals(S1, S2) :-
subset(S1, S2),
subset(S2, S1).
A type declaration for a type T may contain a `where equality is
EQUALITYPRED' specification only if the following conditions are
satisfied:
* T must be a discriminated union type; it may not be an equivalence
type
* EQUALITYPRED must be the name of a predicate with type `pred(T,
T)' and mode `(in, in) is semidet'.
Types with user-defined equality can only be used in limited ways.
Because there multiple representations for the same abstract value, any
attempt to examine the representation of such a value is a conceptually
non-deterministic operation. In Mercury this is modelled using
committed choice nondeterminism.
The semantics of a specifying `where equality is EQUALITYPRED' on
the type declaration for a type T are as follows:
* If the program contains any deconstruction unification or switch
on a variable of type T that could fail, other than unifications
with mode `(in, in)', then it is a compile-time error.
* If the program contains any deconstruction unification or switch
on a variable of type T that cannot fail, then that operation has
determinism `cc_multi'.
* In addition to the usual equality axioms, the declarative
semantics of the program will contain the axiom `X = Y <=>
EQUALITYPRED(X, Y)' for all X and Y of type `T'.
* Any `(in, in)' unifications for type T are computed using the
specified predicate EQUALITYPRED.
* EQUALITYPRED should be an equivalence relation; that is, it must be
symmetric, reflexive, and transitive. However, the compiler is
not required to check this(1).
---------- Footnotes ----------
(1) If EQUALITYPRED is not an equivalence relation, then the
program is inconsistent: its declarative semantics contains a
contradiction, because the additional axioms for the user-defined
equality contradict the standard equality axioms. That implies that the
implementation may compute any answer at all (*note Semantics::.), i.e.
the behaviour of the program is undefined.
-----------------------------------------------------------------------------
--
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.
More information about the developers
mailing list