This page is part of the web mail archives of SRFI 114 from before July 7th, 2015. The new archives for SRFI 114 are here. Eventually, the entire history will be moved there, including any new messages.
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 | cowan@xxxxxxxx advantage of encouraging feedback from others. --James A. Matisoff