12:03 Chouser: When I try to use assert, I get: clojure.lang.Compiler$CompilerException: REPL:1265: No such var: clojure/prstr
12:03 rhickey: should be pr-str, fixed in svn already
12:14 Chouser: ok, thanks
15:42 I think I wish more functions that currently return true or false instead returned an arg's value or false.
15:42 rhickey: which ones?
15:42 Chouser: like "zero?", "or", etc.
15:42 I'm not sure I've thought through the implications.
15:43 Was it a concious decision to not do that?
15:43 rhickey: user=> (or nil 2 3)
15:43 2
15:43 Chouser: Even things like < and > could do it
15:43 oh. :-)
15:44 rhickey: The others are boolean though
15:44 Chouser: zero? wouldn't work
15:44 but pos? might
15:45 if < returned the larger when true, you could chain them: (< (< 5 i) 10)
15:46 rhickey: (< 5 i 10)
15:47 Chouser: hmph.
15:47 rhickey: doesn't negate your idea
15:47 Chouser: you keep shooting down all my good ideas with .. better ones that ... already exist.
15:47 :-)
15:48 ok, so the only one I've stumbled on in my actual code is pos?
15:49 rhickey: there are many, just not or
15:49 Chouser: (some (fn [i] (and (pos? i) i)) seq)
15:49 bgeron: Chouser: what would (< a b) return?
15:49 rhickey: pos? emulates CL plusp
15:50 Chouser: bgeron: either false or b
15:50 bgeron: why b?
15:50 Chouser: because it's the larger
15:50 bgeron: that way (< a (< b c)) doesn't work as expected
15:51 and < is commonly called "lesser-than" or the like
15:51 * bgeron thinks there is no good answer, though, therefore it must return true or false
15:52 Chouser: bgeron: that's a pretty good point.
15:53 I suppose that since < already supports multiple args, the (< (< a b) c) and (< a (< b c)) use cases aren't good ones to look at.
15:53 bgeron: it would be cool if we could use math notation to write a < b <= c
15:53 rhickey: Chouser: your problem might be with some returning the predicate return rather than the found value
15:53 bgeron: that is a good point also
15:53 rhickey: another CL-ism
15:54 Chouser: rhickey: maybe, but I think it makes sense to use the predicate return, since that at least gives you the power to return the found valoue or something else.
15:54 I'll go with power and simplicity over brevity.
15:55 I guess if it gave you the found value you could wrap it in another (map ...). Hm.
15:55 rhickey: CL has separate find-if
15:56 Chouser: yeah, I'm also in favor of fewer builtins
15:57 oh, zero? would work. So is there a reason for zero?, pos?, and neg? not to return their arg when true?
15:58 rhickey: possibly not - running now, will think about it
16:00 Chouser: bgeron: any objections? you had some good ones against <
16:03 bgeron: maybe that it's not consistent with other predicates in returning values other than false/true, but it's really not a problem
16:05 I think returning only false/true is more pure, but it's more practical to return the value itself in zero?,pos?,neg?
17:42 scramflot: hi
17:43 in the definition of the filter function, on page: http://
17:43 (filter pred coll)
17:43 Returns a lazy seq of the items in coll for which (pred item) returns true.
17:45 so, like, (filter (= x 1) [4 1 3 1]) -> [1 1] ??
17:46 or it's a function that takes a parameter and tests it, returning true or false
17:57 Chouser: pred is short for predicate, which means a function.
17:57 In this case at aleast, a function that returns true or false
17:58 (= x 1) is a function call, not a function.
17:58 (filter (fn [x] (= x 1)) [4 1 3 1])
23:38 jh06: Hi guys. I had a question which stems mainly from my misunderstanding of how Lisp works. How come I can redefine if, but the redefined version acts exactly the same as the old one?