Am Sa., 6. Apr. 2019 um 23:00 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

[...]

> Marc Nieper-Wißkirchen scripsit:
>
>> 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.
>
>
> I thought about which calling style to use and decided to go with the same style as max and min themselves, which have the same problem.   Fortunately, there is no variadic recursion in the sample code.

No, but it most Scheme implementation will create a needless copy of
LONG-LIST when only the "(apply comparator-max LONG-LIST)" is
possible.

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

What does that mean? This would mean that any portable use of SRFI 162
has to assume the lowest common denominator. Does this mean that any
portable use of SRFI 162 cannot assume that hash functions are
provided, for example?

>
>>
>> (3) What guarantees can be made about the default-comparator? The same
>> as for a comparator returned by (make-default-comparator) of SRFI 128?
>
>
> Yes, I think that's implicit.

Ok. But why not write it explicitlyly?

>
>>
>> (4) What can be said about the ordering of the real-comparator?
>
>
> That's downright obvious.  Any other interpretation would be perverse.

Again, why not write it explicitly? The ordering of all other
comparators has been specified explicitly.

>
>>
>> (5) Why don't we have eq-comparator, eqv-comparator, and
>> equal-comparator (without an ordering)? They seem to be useful.
>
>
> I debated it, and I'm not sure how useful they actually are.  If I did (Ghu forbid!) SRFI 128 again, I'd probably leave the corresponding constructors out altogether.

Hash tables based on eq? are quite common. So, (make-hash-table
(make-eq-comparator)) is used a lot.

I know that SRFI 125 also allows (make-hash-table eq?) for historical
reasons, but other clients of SRFI 128 like SRFI 146 don't accept raw
comparison functions.

If you ask me, they are certainly useful enough to be included in SRFI
162, all the more so as including them has no adverse effects.

[...]

Thanks,

Marc