Email list hosting service & mailing list manager


Guarantees about the comparators Marc Nieper-Wißkirchen 13 Feb 2019 15:02 UTC

Hi John,

I think this SRFI is a very useful addition to SRFI 128 and should
eventually be finalized an included in R7RS-large.

I'd like to make the following minor comments:

(1) When one needs to find the largest (or smallest) element in a long
list, it would be nice if this SRFI defined a procedure like
"comparator-max-in-list" so that one could write
"(comparator-max-in-list LONG-LIST)" instead of "(apply comparator-max
LONG-LIST)" because the former would need fewer resources.

(2) The specification doesn't state explicitly that all defined
comparators should provide both an ordering and a hash function.

(3) What guarantees can be made about the default-comparator? The same
as for a comparator returned by (make-default-comparator) of SRFI 128?

(4) What can be said about the ordering of the real-comparator?

(5) Why don't we have eq-comparator, eqv-comparator, and
equal-comparator (without an ordering)? They seem to be useful.

Thanks,

Marc