11:37 Chouser: I guess neither recur nor thisfn do what I want from inside a lazy-cons
11:38 rhickey: if you are on the latest SVN you can name your fn like this: (fn name [args]... (lazy-cons x (name ...
11:39 as described here: http://
11:54 Chouser: ah, cool. Well, my function was already named via defn, so I could use its name.
11:54 I just thought recur would be more correct before I realized that it didn't really make sense for lazy-cons
11:55 rhickey: right, and thisfn didn't nest, so it had to go
11:55 Chouser: so then I tried thisfn, thinking that was still "more correct" than refering to my own function by name. That gave me a difficult to understand error.
11:55 wrong number of params.
11:56 I suppose thisfn was refering to a func built by the lazy-cons macro? Anyway, it took me a while to figure that out.
11:56 So now I'm back to the obvious solution that I had at first. ;-)
11:59 rhickey: that's good, sorry for the confusion
12:00 Chouser: no need to apologize. If I had any better idea how I thought it should work, I would suggest it. But I've got nothin'
12:00 Unless... hm, is there any way the "wrong number of args passed" error could give the name of the function you're actually calling?
12:01 ...if it's named.
12:01 or maybe the list of formal parameters? ...except of course there are many such lists for each fn.
12:01 Well, nm.
12:01 Like I said, I've got nothin'
12:02 rhickey: the name might be possible, I'll look into it
12:03 Chouser: It's very good to have the line number of the .clj file in the stack trace. Dunno how hard that was, but it sure helps a lot.
12:05 rhickey: Clojure emits real debug info - I wish more of the Java debuggers could deal with non-java files
12:06 Chouser: I think that's a problem with the whole IDE mentality... Giant stacks of code and tools all assuming some particular source language.
12:07 Maybe one day when we have the perfect language such effort will be justified. But for now I think it just helps lock people into old languages.
12:08 rhickey: but these days they know it could at least be JSP or Javascript, yet each gets special-cased...
12:08 Chouser: rhickey: have you looked at arc at all? I'm a bit curious what you think of its goals, syntax decisions, etc.
12:09 rhickey: I'm very envious of the attention it gets, but haven't looked at the language in detail. On the surface it seems to have a lot less going for it than Clojure ;)
12:11 Chouser: heh. yeah. If you'd published a couple popular books (and maybe made a million dollars) first, I bet clojure would get more attention.
12:11 rhickey: I'm working on it
12:11 Chouser: but I tend to agree. I wouldn't claim to know much about lisps, but I wrote a couple projecteuler solutions in arc, and was a bit disappointed.
12:12 I like some of the conventions that it has, but I can whip up a couple macros to give me that in clojure, and then I still get access to Java libs, namespaces, etc.
12:13 I like arc's (if) ... the power of (cond) with the simplicity of CL (if)
12:15 rhickey: I think other things are much more important - especially abstractions for the core data types
12:15 Chouser: yes, I agree.
12:16 like I said, if I want arc's (if) bad enough, I can write a pretty simple macro in clojure to get it (although any other clojure user might be annoyed while reading my code).
12:16 rhickey: Clojure cond is pretty lean already
12:17 Chouser: but trying to write macros in arc to get abstract data structures would be a *huge* pain, even if it were possible.
12:18 I played with scala a bit before picking up clojure, and the similarities and differences are interesting.
12:18 both have data structure abstractions, but scala is much more "classical" in it's OO.
12:19 I haven't done objects/classes/type tag stuff in clojure yet
12:20 rhickey: Clojure is much simpler than Scala
12:20 Chouser: Scala comes with the kitchen sink pre-installed.
12:21 But of course it also has static typing -- I'm not sure which I prefer on the front.
12:21 Scala has no macros, which is a big strike against it.
12:25 But I can't say I like lisp's lack of syntax. Clojure's [vectors] help a little, but I guess nobody willing to invest a bunch of time in creating a lisp is likely to see a need for more syntax.
12:37 oh! cond returns nil?
12:38 I guess its nested ifs for me.
12:47 rhickey: ? cond returns the value of the matching expr
12:48 takes an even number of args, this is not Arc :)
12:55 Chouser: http://
12:55 "(cond) returns nil"
12:56 oh! And my problems was I was passing a list of lists of 2 items each.
13:02 rhickey: right - Clojure doesn't need those extra parens
13:06 Chouser: cool. What about that line in the docs? Did I misunderstand it, or is it incorrect?
13:08 rhickey: I thought you meant cond always returns nil. Yes (cond) returns nil.
13:12 Chouser: oh! ha. ok, so I misused the macro, and then misread the docs.
13:12 ericthor: there is a netbeans plugin and it's very easy to use
13:13 oops...wrong room
15:13 rhickey: insvn - compiled regex literals #"pattern" - #"[0-9]+"
15:14 (re-seq #"[0-9]+" "abs123def345ghi567") -> ("123" "345" "567")
15:15 la_mer: rhickey: oooh, very nice :-D
15:15 Does this mean reader macros are coming, or is this bolted into the runtime?
15:17 rhickey: It's a reader macro, but I still am not opening up the reader at this time
15:17 (let [[a b] (re-matches #"([-+]?[0-9]+)/([0-9]+)" "22/7")]
15:17 [a b])
15:17 -> ["22" "7"]
15:18 la_mer: FYI, I'm afraid that the eclipse plugin hasn't gotten much love over the past weeks. Work has been absolutely nuts.
15:18 rhickey: hopefully the namespace stuff will help
15:20 la_mer: That's also nice. I would think it'd be ideal if the regex literal yielded a fn that returned an easily destructurable vector when passed a string to match against.
15:20 Yeah, the namespaces will make everything a lot easier.
15:21 It's just a matter of getting a few spare hours over a couple of weekends to mash everything together (and unwind the eclipse API's along the way).
15:22 rhickey: I think hardwiring the vector might be limiting, useful sometimes but not others
15:22 e.g. the sequence case
15:33 Chouser: could #"" return a regex object that also implements IFn?
15:34 rhickey: The problem is it would no longer be a Pattern for use by the rest of the Java API, as it is now (Pattern is final)
15:34 Chouser: Ah. ok.
15:53 hash- and sorted-maps are immutable?
15:55 rhickey: yup
15:56 Chouser: so is there something better I should use for memoizing, where I'm going to be doing a lot of one-at-a-time inserts?
15:56 Or do they perform ok for that.
15:58 rhickey: they are very good, IMO. but java.util.concurrent.ConcurrentHashMap is still available - depends on the use case
15:58 The compiler uses the persistent collections extensively
15:59 and if you ever need to snapshot or branch, nothing can compete
16:00 Chouser: right, I (am beginning to) understand the huge value of immutable data and how to work with it, but I really need to have fast inserts.
16:00 I'll try with hash-map first and see how it goes.
16:02 rhickey: I benchmarked against the Java collections a good bit, the Clojure collections are within striking distance, and sometimes the lookup of the hash-map is faster. By all means try to use them and let me know if it becomes the bottleneck.
16:03 Chouser: it must not copy the entire data set for each insert?
16:04 rhickey: that's right
16:26 Chouser: turns out I only need a couple hundred inserts. plenty fast.
16:31 rhickey: (defn test-map [n]
16:31 (loop [m {} i 0]
16:31 (when (< i n)
16:31 (recur (assoc m i i) (inc i)))))
16:32 user=> (time (test-map 100000))
16:32 "Elapsed time: 322.976 msecs"
16:33 Chouser: :-)
16:33 now I just need to figure out why my algorithm is failing.
21:12 Could I use defmulti to define my own data structure that implements ISeq or whatever?
21:13 rhickey: look at bean in the latest boot.clj for an example of implementing IPersistentMap
21:14 lazy-cons implements ISeq pretty easily
21:14 Chouser: ok
21:14 rhickey: but multimethods don't map to Java methods
21:18 Chouser: (implement ...) huh, ok.