This page is part of the web mail archives of SRFI 114 from before July 7th, 2015. The new archives for SRFI 114 contain all messages, not just those from before July 7th, 2015.
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