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.
David Banks scripsit: > Overall this is an amazingly rich API and I look forward to using it > when it is standardized. I hadn't ever clocked the existence of the > previous SRFI, so this is a nice surprise. Nor had I. I submitted something much simpler, and our Kindly Editor pointed me to SRFI 67. I withdrew my previous submission and made this one instead. > I guess the intention is that if I want a less specific behaviour I > can use the numeric comparators under the 'Standard atomic > comparators' section, or 'default-comparator'. Just so. > Why not let the user specify the actual rounding procedure to use for > the rounding parameter of 'make-inexact-comparator', instead of using > a symbol? Performance? No, but because the small language does not support two-argument rounding functions beyond truncate and floor. I'll add support for a procedure as well. > I don't really see the need for the procedures under 'Primitive > applicators'. They are just sugar, I guess, unless the results of the > accessor procedures are intended to be totally opaque. (except for > comparator-check-type which has additional semantics). i.e. can the > semantics of (comparator-hash comparator obj) differ from > ((comparator-hash-function comparator) obj) in any way? No, it doesn't. However, I think it is easier to read. Originally I had just the applicationrs and not the accessors; then I saw that the accessors would be required too, and added them. One nice feature about large libraries like this is that when writing the more complex procedures, you quickly find out which more primitive ones are lacking. > I'm a little worried that the binary comparison predicates look too > similar to the existing base comparison predicates. (=? c x y) is > fairly visually similar to (= c x y). That's true. > Also not sure of the use case for allowing ((=? cmp) x y) as part of > the same procedure, I see that this is useful for expressions like (<? > cmp) where the resulting procedure is not identical to the result of > 'comparator-compare-procedure', but maybe bundling this neat currying > behaviour under general comparison is muddying the waters. It's true that currying =? and not=? are redundant, since comparator-equality-predicate is already a predicate. But it seems best to have all six of them. Let me know if you think it's a good idea to split out the currying versions from the regular versions under a different name. > Nice work! Thanks! -- Knowledge studies others / Wisdom is self-known; John Cowan Muscle masters brothers / Self-mastery is bone; cowan@xxxxxxxx Content need never borrow / Ambition wanders blind; http://ccil.org/~cowan Vitality cleaves to the marrow / Leaving death behind. --Tao 33 (Bynner)