I'd say the simplest answer is just that functions *are* values, they are never logical-false, and (not) is based on logical falseness. Giving (not) a special case for functions would make it less composable by trying to make it do more.
-James On Tuesday, 6 November 2012 14:55:53 UTC-5, Charles Comstock wrote: > > I understand that, hence the example being to check if the value was a > function, since returning false from not'ing a function didn't make sense > to me. The change I was inquiring about applied to your example would be; > > (filter (fnot even?) [1 2 3 4 5 6 7]) => (1 3 5 7) > (filter fnot [true false true]) => [false true false] > > So I fully understand that one is operating on values, and one is > operating on functions. What I was asking, is if it's ever useful to > execute not on a function but treat it as a value, just as it doesn't make > sense to execute complement on values instead of functions. Given that it > seemed the vast majority of use cases are distinct dependent on if you are > dealing with functions or values, I was questioning if the functions could > be combined to do the right thing depending on if it was a value or a > function. I was asking for arguments for and against that, but concluded it > was probably was due to complecting and was asking for verification. > > Thanks, > > Charlie > > On Tuesday, November 6, 2012 4:03:44 AM UTC-6, Stathis Sideris wrote: >> >> The difference between not and complement is that not takes a *value* and >> produces a new *value* which is true if the original was false (and vice >> versa) while complement takes a *function* and produces a new *function >> *which >> returns true in the cases where the original function would return false. >> >> Here is an example that shows how complement can result in more concise >> code in comparison to not: >> >> user> (filter (fn [x] (not (even? x))) [1 2 3 4 5 6 7]) >> (1 3 5 7) >> user> (filter (complement even?) [1 2 3 4 5 6 7]) >> (1 3 5 7) >> >> (of course you could just use odd? in this case, but it's only an >> example). >> >> I hope that clears it up. >> >> Stathis >> >> On Monday, 5 November 2012 23:12:03 UTC, Charles Comstock wrote: >>> >>> Hi All, >>> >>> I quite like Clojure but have been confused from time to time on >>> particular design choices. I find understanding the root cause of these >>> decisions helps to understand the language better. As example, the fact >>> that complement and not are separate functions has been puzzling me for a >>> bit [1]. The implementation of not and complement is roughly; >>> >>> (defn not [x] (if x false true)) >>> (defn complement [f] >>> (fn >>> ([] (not (f))) >>> ([x] (not (f x))) >>> ([x y] (not (f x y))) >>> ([x y & zs] (not (apply f x y zs))))) >>> >>> What I'm wondering is if it's purely for performance, historical or >>> idiomatic reasons that it's not; >>> >>> >>> (defn fnot [arg] >>> (if (ifn? arg) >>> (fn >>> ([] (fnot (arg))) >>> ([x] (fnot (arg x))) >>> ([x y] (fnot (arg x y))) >>> ([x y & zs] (fnot (apply arg x y zs)))) >>> (if arg false true))) >>> >>> Perhaps a multi-method could also be appropriate here, though I'm not >>> exactly certain what the appropriate dispatch function would be. I follow >>> why bit-not is a separate function as the intended meaning is clearly >>> different, but the implied meaning of not seems to be the same as >>> complement which is why it seems odd that they are different methods. >>> >>> After doing some experimentation with these, I finally realized that (not >>> identity) yields false, but I'm not quite following that use case. I'm >>> guessing the idiomatic argument against fnot is that it would complect not >>> and complement unnecessarily? >>> >>> While pouring through the clojure.core source, I also saw a few functions >>> like not-every? which use (comp not every?) instead of (complement every?). >>> This led me to question why complement is not implemented as; >>> >>> >>> (defn complement [f] (comp not f)) >>> >>> >>> Is there a difference that I'm just not seeing? Or is that just a side >>> effect of either performance or dependency ordering in clojure.core [2]. >>> >>> I think I may have answered my own question concerning fnot in a roundabout >>> manner, but I found the process of discovering this illuminating. Can >>> anyone else shed light on this, or am I correct in concluding that fnot >>> would complect not and complement? >>> >>> Thanks, >>> Charlie >>> >>> 1. I frequently misread comp as complement and not compose in point free >>> code, so perhaps that confusion is why complement is oddly jarring to me. >>> >>> 2. not-every? and not-any? are implemented using def instead of defn and >>> manually set meta :arglist, despite defn already being defined, is this >>> just for historical reasons? >>> >>> >>> -- 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
