>From: John Cowan <xxxxxx@mercury.ccil.org>
Subject: Re: New release of SRFI 114 with implementation
Date: Wed, 4 Dec 2013 15:49:46 -0500

>> 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.

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).

>> 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":

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

Certainly having `comparator?' is an advantage, and implementations
that choose closures would have a difficulty there.  However, I've
fancied "procedure attributes" before, which is immutable attributes
one can query to a procedure object.  If an implementation have that
kind of extension, it can provide `comparator?' as well.  And for
the implementation that allow maps, `comparator?' can just check
whether it has suitable entries.  Anyway, we can leave implementations
to provide a reasonably reliable `comparator?' without requiring
comparators to be a separate type.  So the API can be intact.

--shiro