On Nov 23, 1:23 am, Rich Hickey <[EMAIL PROTECTED]> wrote: > I still don't understand your expectation here. If the filter does any > filtering, it won't return everything in the vector, so the new result > will have fewer items. Do you want a vector with fewer items? Then > you'll have a new vector.
Sure. But I get a seq and not a vector. Now don't get me wrong - I like the whole sequence library. It's just the performance cost to get a vector back. That's why I mean relative to seqs the data structures sometimes feel like second class. In my example I no longer use a vector to hold items even though that would be the most appropriate data structure. To be more specififc: I have agents whose state is a vector (used as a buffer) of messages. There are a couple of transformation functions, e.g. tagging messages, removing messages from the vector etc. which are implemented with map and filter. In addition when messages are appended to the vector, conj is used and messages end up at the end of the vector. Later I noticed that the order was screwed because some intermediate tagging (using map) returned a secuence as the new agent's state and later additions with conj prepended messages at the front. This motivated me to ask for the simplest and most efficient way to get a vector back because that's what I wanted. Now I use a list instead of a vector and use reverse when necessary. > In general, it can be efficient to perform a series of transformations > in the seq space and then realize a vector at the end if you want. The > lazy seqs just act as a cursor over the data, and a stream of results, > and building a new vector from scratch by appending, as vec or (into > [] ...) would do, is more efficient than element 'replacement'. > > If you don't expect a copy when mapping across an entire vector, and > you want to use the immutable data structures, what alternative do you > imagine? I certainly don't want to move away from immutability. It's more an issue with the return types. In the example setting outlined above suppose I have a message buffer (vector) of length n. Now some messages need to be tagged, which means mapping over the vector and possibly changing some messages. Now by changing I mean of course that the message m which is a map is transformed into m' where m' has some :tag key for instance. This mapping over the vector gives me a seq, i.e. the type has changed from vector to a sequence and this type change will cause later appending to the buffer to bahve differently. Now, to get a vector back I was told to use vec which AFAICS is very costly. Your proposal to use reduce in order to build up the new vector was a very good suggestion. For mapping at least. But the general issue for me was the type change. What would I propose? Not sure. I guess this behavior is by design and if I would want to get vectors there ios no way around copying. Which lead me to my conclusion that I better use a list instead of a vector. However it didn't give me that warm and fuzzy feeling that I normally get when programming in Clojure. Sorry that I can't be more specific than this. --~--~---------~--~----~------------~-------~--~----~ 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 To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
