On 12/07/2013 07:13 PM, John Cowan wrote:
> 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.

Yeah, I was looking at
http://srfi.schemers.org/srfi-114/srfi-114.html .
The draft at
http://ccil.org/~cowan/temp/srfi-114.html
has indeed addressed these two issues.

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

Returning the first tied argument seems like it would be a little more
straightforward to implement, at least to me. But I'm comfortable with
the current behavior. I don't think it matters much as long as the
behavior is documented.

Kevin Wortman