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.
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. A few miscellaneous comments: I find it strange initially that I'm forced to specify the various arguments for 'make-inexact-comparator'. I would like to have optional arguments that simply use the default behaviour of the = operator (for instance) if I don't specify the argument for 'epsilon'. 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'. 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? 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? 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). 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. Nice work! Cheers, -- David Banks <amoebae@xxxxxxxxx>