[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New release of SRFI 114 with implementation

This page is part of the web mail archives of SRFI 114 from before July 7th, 2015. The new archives for SRFI 114 contain all messages, not just those from before July 7th, 2015.

From: John Cowan <cowan@xxxxxxxxxxxxxxxx>
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.