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

[Mark Brown]

On 12-Apr-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 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.

Ok.

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

Agreed.

> However, those can be done later.

Ok.

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

I did consider this.

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

This was the approach I tried first.  The problem is that the generic
routines can call the type specific routines in the type_ctor_infos.  So if
we want the compare_representation routines to be separate from the compare
routines, we will need to add a new field to type_ctor_infos to store the
address of a new type-specific procedure, which we will also have
responsibility to fill in correctly.  The new type-specific procedure would
be the same as existing compare, except that it would recursively call the
new generic procedure rather than the existing one.  I deemed this to be a
much larger maintenance problem than the global variable approach.

A pure approach would be to pass an extra argument to compare, similarly
to what we do with deconstruct, etc.  In this case, though, the performance
impact would be much more significant, so I didn't think it would be worth
it given that the existing comparison would be used most of the time.

Given the above, I'm still inclined to think that the global variable
approach is the best option.  The documentation of it could be improved,
though; I'll post a relative diff soon.

Cheers,
Mark.

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