A couple nitpicks: > Right, and that's also the reason why there should be not=, with a default > implementation that does (not (= ...)). It can be expensive to establish > equality for a complex data structure, whereas inequality can be ascertained > at the first difference encountered.
In those cases, = can return false just as quickly as not= can return true. I don't see how there can possibly be a performance difference, unless you want to implement generic/= and generic/not= that don't satisfy (= (generic/= a b) (not (generic/not= a b))), which seems like a pretty uniformly bad idea to me. > Along the same lines, <= has a default implementation that does (not (> > ...)), but it is possible to provide specific optimized implementation for > any argument type. Note that this is actually incorrect for floating point path, because both (<= 1 Double/NaN) and (> 1 Double/NaN) should be false. -Jason -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
