Kevin Wortman scripsit:

> I presume that the convenience behavior when compare or hash are #f, is
> provided to support objects that are orderable or hashable but not both.
> This is reasonable, but it seems like there needs to be some method of
> introspection to determine whether one of a comparator's procedures
> is effectively missing. A hash table may want to raise an error when
> given a non-hashing comparator, for instance.

You are apparently looking at an older version of the SRFI document.
The current version has the predicates `comparator-comparison-procedure?`
and `comparator-hash-function?` for this very purpose.

> Binary comparison predicates
> Chain (multiple argument) comparison predicates
>
> Why not have only the chain predicates, with the short names used for
> the current "Binary comparison predicates"?

This is now the case.

> Min/max comparison predicates
>
> When multiple arguments are tied for minimum/maximum, which one is
> returned? This matters when the minimal/maximal objects are equal
> according to the comparator but not according to eqv?.

An excellent point.  The current implementation produces the last
minimal/maximal argument; are there any objections to making this the
standard?

--
Being understandable rather than obscurantist poses certain
risks, in that one's opinions are clear and therefore     | John Cowan
falsifiable in the light of new data, but it has the      | xxxxxx@ccil.org
advantage of encouraging feedback from others.  --James A. Matisoff