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.
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. cowan@xxxxxxxx
--Susan McCarthy (adapted)