[m-rev.] for review: comparison of preds/funcs

[Zoltan Somogyi]

On 12-Apr-2002, Mark Brown <dougl at cs.mu.OZ.AU> wrote:
>  One question is: is the
> following feature generally useful enough to be part of the standard
> library?  If so, I'll add a NEWS entry, otherwise I'll move it into the
> browser directory.  My vote is that it is generally useful.

I agree.

> Implement compare_approx/3, which is like compare except that it is cc_multi,
> and it doesn't abort on pred and func types.

Two comments. First, the name shouldn't be compare_approx; it should be
something like compare_representations. The comparison is not approximate;
it differs from standard compare in that it compares terms' representations,
not their semantic values.

Second, the new predicate should differ from standard compare not only in how
it handles predicates and functions, but also in how it handled all
noncanonical types. For example, it should be able to compare values of
types with user-defined equality. The debugger will need that too.
However, those can be done later.

> runtime/mercury_ho_call.c:
> runtime/mercury_ho_call.h:
> 	Add a global variable which says which kind of comparison we are
> 	doing.  Implement the function MR_compare_closure_approx which
> 	compares closures.

Again two comments. First, MR_compare_closure_approx should just be
MR_compare_closures. Second, using a global variable in this way is not
a good idea. Although its performance impact can be neglected, the fact
that it adds state to an algorithm that didn't have one before will complicate
future maintenance. Instead of checking the value of this new global variable,
the code in mercury_unify_compare_body.h should instead check whether a new
macro is defined or not. You can then make the implementation of the new
predicate mercury__compare_representations_3_0 define this macro while
mercury__compare_3_3 leaves it undefined. You will also need a new function
MR_generic_compare_representations, which also differs from MR_generic_compare
in that it defines this optional new macro (plus of course the definitions
of the recursive calls).

Please send a new diff when you have addressed these points.

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