[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New release of SRFI 114 with implementation
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
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