Well, I don't know if it's an explicit design goal of transients to not support these kinds of operations or if noone felt the need for them strongly enough to implement them.
I believe transients are not meant to be the final solution to the problems which are currently addressed through their use -- see the various mentions of pods for hints at an interesting direction in this design space. This might be relevant in that one might feel less inclined to work on code which is already meant to be replaced completely if there's no pressing need to do so. Issues to think about -- seq would have to deal with the possibility of the transient changing from under the seq, though that's also true of arrays, say, so probably not a big deal. Reduce could work fine, but one should probably enforce that it only happens on the owning thread (although something like fold could still distribute work among multiple threads as long as the owning thread called it and blocked waiting for the result). NB. calling persistent! then transient again from time to time is likely not a big deal. The immediate cost is an allocation of the persistent object followed by two allocations -- of the transient and of an AtomicReference to the current thread. (There's a small handful of field reads and assignments in ctors.) Then there's a further cost of reallocating the editable nodes inside the transient -- just once, when the node is first modified. If in between reductions you modify different parts of the transient, that second part of the cost won't even be there. Cheers, M. On 16 May 2012 19:30, nicolas.o...@gmail.com <nicolas.o...@gmail.com> wrote: > So, if I have a transient and want to reduce it and then continue to > use it transiently, > I need to call persistent!, reduce and transient again. > > Is there a reason for that? > > (The documentation says that read operation are allowed. And it is > actually possible > to write a reduce for a transient vector.) > > -- > 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 -- 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
