Shiro Kawai scripsit:

> I can't come up better wording, though.  Maybe we can say "The
> comparator objects ... are not applicable to circular structure
> otherwise noted", and note the "circular-structure-safeness" in some
> comparators.

I've adopted that, and marked the {eq,eqv,equal}-comparators
as accepting both circular structure and NaNs, and the
inexact-number-comparator as accepting NaNs.

> 2. Optional comparator in comparison predicates.  The rationale of
> allowing it is "there is no comparator for comparators, so there is
> no ambiguity", but why not?  There won't be a portable way, but some
> implementations may allow it.

SRFI 67's approach is to allow only two objects for =? and friends;
there are another set of predicates which accept two or more arguments
and require a comparator.  That seemed un-Schemely to me.  In any case,
if either an explicit comparator or the default comparator is able to
compare comparators, the user can always pass it by default.  The only
thing that doesn't work is comparing comparators *implicitly* using the
default comparator.

> (=? comparator obj1 obj2 obj3 ...) can be written as ((make=?
> comparator) obj1 obj2 obj3 ...), which is a bit verbose but I think
> it's much clearer and I would prefer latter.  I don't mind dropping
> 'comparator' support in =? etc. and just define =? as (make=?
> default-comparator)

The idea of =? is to explain the notation used in the Scheme reports of
being "the same in the sense of X" where X is some predicate.  Here we
supply a comparator rather than a predicate.

> 3. Disjoint comparator type.  I have a mixed feeling on it.  It would
> be convenient to have comparator? work, and it might be necessary
> to overload some procedures such as 'set', which can take either a
> comparator or equality predicate.  OTOH, having a disjoint type just
> to bundle some procedures seems overkill in Scheme---it smells more
> like class-based OO language, in which people always need to pass an
> instance of a class where Lispers would just pass a closure.

That was my original design, to have a closure which would accept a
symbol argument saying what to do.  But there are several disadvantages
to such "poor man's objects":

1) The symbols cannot be renamed using the module system, as access
procedures can be.  To be sure, the symbol could be held inside a global
variable of fixed name, but it's still more awkward to use.

2) Matching on the symbol name is typically much less efficient than
retrieving a component of a record.  This can matter when the procedure
will be invoked many times, and it would be necessary for users to cache
it.

> BTW, an implementation may want to provide multiple comparator types
> (e.g. by subclassing or duck-typing).  The "disjoint type" clause can
> be refined to say from what the type is disjoint.

Certainly a type cannot be disjoint from its subtypes!  It's hard
to articulate at this stage exactly what "disjoint type" means:
the intention is for it to be disjoint from all the other types of
R7RS-large, but we can't enumerate them all yet.

--
John Cowan
        xxxxxx@ccil.org
                I am a member of a civilization. --David Brin