[m-rev.] for review: list__sort_and_remove_equivs/3

[Mark Brown]

On 06-Sep-2002, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> Fergus Henderson, Friday,  6 September 2002:
> > <shrug>
> > 
> > I would have no objection to deprecating this version.
> 
> How about declaring the new version to be a bugfix rather than
> deprecating it and introducing a new name?  Since the current
> documentation doesn't say exactly what constitutes duplication, we'd be
> well within our rights.

Upon further investigation, I came to the same conclusion.  For one thing,
list__merge_and_remove_dups treats X and Y as duplicates if Compare(X, Y, (=))
is true, so we don't currently have a consistent definition of "duplicates"
in the case that Compare(X, Y, (=)) does not imply X = Y.

As I mentioned earlier, we apparently assume that Compare(X, Y, (=))
implies X = Y, so the above inconsistency is not an issue.  I'm prepared
to make the changes required, but I need some feedback on the following:
do we wish to keep this assumption or throw it out (I vote for the latter)?

If we want the latter, I'll fix the code and comments in list.m so that
we avoid the assumption.

If we want the former, I'll document the requirements on comparison
predicates.  Probably the best way to do this is to add new types:

	:- type comparison_pred(T) == pred(T, T, comparison_result).
	:- type comparison_func(T) == (func(T, T) = comparison_result).

and document the requirements there.  Preds/funcs that take comparison
arguments will then be modified to use this type.

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