Shiro Kawai scripsit:

> Right.  And the current description doesn't prohibit
> default-comparator to compare comparators.  So if you get some
> arbitrary Scheme objects and want to apply =? etc., you have to
> pass the comparator argument explicitly anyway.  You can omit the
> comparator only when you're absolutely sure the first argument isn't a
> comparator.  Thus I feel that omitting the explicit comparator isn't
> that useful, and it isn't worth regarding to the risk of forgetting
> the possibility of obj1 happening to be a comparator (it would make a
> hard-to-reveal bug).

Okay, I'm convinced, especially by the last point.  I've changed my copy
of the SRFI and the implementation, but I'll wait on pushing this to the
site.

> I agree with those disadvantages, and I'm not saying the standard
> should use closures.  My point is to allow implementations to use
> closures if it wants to.

This argument seems to be perfectly general.  As we know, closures can
emulate any data structure, so what is the argument for making, say,
pairs and procedures disjoint?  Well, it's more convenient to be able
to do type dispatching without worrying about whether pairs might be
procedures.  I think the same argument applies here.

> Or to allow a 'map' with suitable entries i.e. in Clojure notation,
> something like {:type? type-pred, :equal? equal-proc, :hash hash-proc}

Now the situation becomes more complicated yet: comparators might be
hash tables or procedures or even both (since hash tables might be
procedures).  I fear this will upset Scheme's existing balance between
rigid (though dynamic) typing and duck typing.

--
Evolutionary psychology is the theory           John Cowan
that men are nothing but horn-dogs,             http://www.ccil.org/~cowan
and that women only want them for their money.  xxxxxx@ccil.org
        --Susan McCarthy (adapted)