#clojure log - May 26 2008

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

1:15 abrooks: Hrm. xml/emit-element does not properly escape XML entities.

1:53 Has anyone use xml-stream-reader.clj?

1:53 I'm properly steeped in Java to grok the context, I think.

1:53 I'm looking for examples if anyone has them.

11:25 rapido: how hard would it be to allow meta-data for *all* types, not only for collections or symbols?

11:31 rhickey: impossible, as many types, like String are final

11:31 and I don't want to require wrappers

11:32 rapido: can't you just keep a separate global map that maps any object to its meta data?

11:32 (i know global is evil)

11:32 rhickey: there is that

11:33 plus, the original concept of metadata coincides with data as values - with-meta produces a new object

11:33 any global cache would be identity-basec

11:33 based

11:33 metadata on Vars is an anomaly

11:34 rapido: still, i feel the concept can be pushed a lot further

11:35 rhickey: well, java.util.concurrent is there

11:36 rapido: does java.util.concurrent have something similar to meta-data?

11:37 rhickey: no, just the tools to build the global map you want

11:39 actually, maybe not, as no concurrent identity map

11:41 rapido: i have been looking at PersistentHashMap which is nice, performance wise

11:41 rhickey: thanks

11:41 rapido: but i feel PersistentVector could be implemented similarly fast.

11:41 do you know about ropes?

11:42 rhickey: how is persistent vector not similarly fast?

11:42 same data structure

11:42 rapido: is it possible to concatenate two vectors?

11:43 in O(log(n))?

11:44 rhickey: no, nothing that virtualizes concat for vector

11:45 rapido: i think you should do an implementation that's optimized for vectors

11:45 rhickey: of concat?

11:46 rapido: concat, head, tail, subvector etc. all the important operations

11:47 rhickey: I don't think vector concat is important

11:48 head/tail/conj/subvector are all smoking, as is initialization with an existing array

11:48 rapido: let's say you have a sequence of chars

11:48 Chouser: rapido: wouldn't it be pretty easy to write an object that holds two (or more) vectors, and translates the operations you need to the underlying vectors?

11:49 rapido: fast concatenation of string would be nice not?

11:49 string<-strings

11:49 rhickey: There is fast concat, it just doesn't yield a vector

11:49 rapido: is it lazy?

11:49 rhickey: lazy-cat is

11:50 rapido: where can i find fast concat and what algorithm is used?

11:50 rhickey: um, the source for concat?

11:51 boot.clj

11:51 gotta run

11:53 rapido: but if you repeatedly concat *n* times you end up with a linear structure that resembles a linked list

11:54 but if the (lazy) structure would be balanced with using a tree balance algorithm you would still have good performance for all operations

11:54 chouser: does that answer your question?

11:55 chouser: that's how the ropes data structure works, see http://ahmadsoft.org/ropes/

11:56 replace strings(=sequence of chars) with any sequence of objects

11:58 Chouser: Yeah, I see your point.

11:58 The Clojure data structures (vector, etc.) are written in Java. There's no reason you can't write your own if you have an application that needs a certain performance profile.

12:01 rapido: sure. it's the old 'library' versus 'build-in' debate :)

12:02 nevertheless, there are many more interesting immutable data structures

12:02 Chouser: yup.

12:03 It'll be interesting to see how that debate plays out over time.

12:03 rapido: avl trees, alpha-beta trees, etc. etc.

12:03 Chouser: I think Rich wants to keep the core language pretty small, which seems like a good idea.

12:03 We've got clojure-contrib as a semi-official place to offer general-purpose code.

12:04 rapido: i saw (one of) his presentations which are very good.

12:04 Chouser: I always liked how Python gives you such a large library be default. It'll be interesting to see where Clojure ends up.

12:05 rapido: i also very strongly believe that mutability is evil, but for more reasons than concurrency

12:06 still, keeping mutability *out* of all the frameworks will be difficult

12:07 Chouser: I'm not deeply familiar with this stuff, but in order to have complete immutability, don't you need monads? I think Clojure has chosen a more practical approach of carefully controlled mutability.

12:08 rapido: i've implementation my own (research) language that pushed immutability to the extreme

12:08 Chouser: ah

12:08 rapido: data, code, computations, environments are all immutable (without using monads)

12:09 i've done several implementations in java, factor, haskell and (finally) scala

12:10 haskell was nice but when i wanted to add io, the code turned into an ugly mess

12:10 chouser: do you know factor?

12:11 Chouser: nope

12:11 * Chouser reads wikipedia

12:15 rapido: what i don't understand why slava, the factor developer, has moved away from the jvm

12:15 i think that was his biggest mistake

12:16 you can't beat the libraries and the cummulated thousands of man years of (compiler) research that went into the jvm

12:17 Chouser: yeah

12:17 rapido: i think rich made very a good choice there

12:21 chouser: so what's your take/interest on clojure

12:21 ?

12:26 got to go... later..

13:59 leafw: I have just sent a feature proposal to the mailing list: embedding java code -like python weaver package. Would be great.

14:00 to have the best of both worlds ... convenience+power, and speed where it matters.

15:55 Chouser: rhickey: I'm poking at the code in the "embedded java" post to the group.

15:56 ImageJ beat me up, so I'm using: (def pix (into-array (for [x (range 512) y (range 512)] (+ x y))))

15:57 on my computer: (time (dotimes i 10 (/ (apply + pix) (count pix)))) ; 863.762673 msecs

15:58 oh, nm -- I don't have anything interesting to say yet. Sorry.

16:05 well, one thing is sort interesting: (reduce + pix) is pretty much the same speed as (reduce long/+ pix)

Logging service provided by n01se.net