David Banks scripsit:

> Overall this is an amazingly rich API and I look forward to using it
> when it is standardized.  I hadn't ever clocked the existence of the
> previous SRFI, so this is a nice surprise.

Nor had I.  I submitted something much simpler, and our Kindly Editor
pointed me to SRFI 67.  I withdrew my previous submission and made
this one instead.

>  I guess the intention is that if I want a less specific behaviour I
> can use the numeric comparators under the 'Standard atomic
> comparators' section, or 'default-comparator'.

Just so.

> Why not let the user specify the actual rounding procedure to use for
> the rounding parameter of 'make-inexact-comparator', instead of using
> a symbol?  Performance?

No, but because the small language does not support two-argument
rounding functions beyond truncate and floor.  I'll add support
for a procedure as well.

> I don't really see the need for the procedures under 'Primitive
> applicators'.  They are just sugar, I guess, unless the results of the
> accessor procedures are intended to be totally opaque.  (except for
> comparator-check-type which has additional semantics).  i.e. can the
> semantics of (comparator-hash comparator obj) differ from
> ((comparator-hash-function comparator) obj)  in any way?

No, it doesn't.  However, I think it is easier to read.  Originally
I had just the applicationrs and not the accessors; then I saw that
the accessors would be required too, and added them.  One nice feature
about large libraries like this is that when writing the more
complex procedures, you quickly find out which more primitive ones
are lacking.

> I'm a little worried that the binary comparison predicates look too
> similar to the existing base comparison predicates.  (=? c x y) is
> fairly visually similar to (= c x y).

That's true.

> Also not sure of the use case for allowing ((=? cmp) x y) as part of
> the same procedure, I see that this is useful for expressions like (<?
> cmp) where the resulting procedure is not identical to the result of
> 'comparator-compare-procedure', but maybe bundling this neat currying
> behaviour under general comparison is muddying the waters.

It's true that currying =? and not=? are redundant, since
comparator-equality-predicate is already a predicate.  But it seems
best to have all six of them.  Let me know if you think it's a good
idea to split out the currying versions from the regular versions
under a different name.

> Nice work!

Thanks!

--
Knowledge studies others / Wisdom is self-known;      John Cowan
Muscle masters brothers / Self-mastery is bone;       xxxxxx@ccil.org
Content need never borrow / Ambition wanders blind;   http://ccil.org/~cowan
Vitality cleaves to the marrow / Leaving death behind.    --Tao 33 (Bynner)