Re: New release of SRFI 114 with implementation John Cowan 05 Dec 2013 18:35 UTC
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)