Different reactions: 1. The reduce solution is O(n .log n) + time of mapping elements, as inserting in a map is O(log n). A tree with n leafs and arity at least binary is of size at most 2n. So a map on a map could be done in O(n) + time of mapping elements, but it would need a bit of support from runtime.
My question was : is there such support in runtime? Is it planned? Would such a patch be welcomed or not? 2. lazy maps would not be performant. A seq of pairs would have a O(n) look up. Clojure hash-map and sorted-map have a O(log n) look up. Having a seq of pairs can be done manually but is less useful than real maps. 3. reduce is strict because it is a consumer. The co-operator of reduce is a producer and should be lazy. reduce type is (a -> b -> b) -> (seq a) -> b a co-reduce would be : (a-> (a , b)) -> a -> (seq b), meaning, with a state, you produce an element and another state(a is the type of state and b of element). It is often called unfold and would be a nice addition to clojure.contrib. I think that most lazy sequence can provably be written as (), cons and unfold, but I am not sure and have no reference in mind. Best, Nicolas. -- 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
