#clojure log - Feb 14 2008

The Joy of Clojure
Main Clojure site
Google Group
List of all logged dates

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://clojure.sourceforge.net/reference/sequences.html , what does "pred" mean?

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?

Logging service provided by n01se.net