I don't think you understand. clojure data structures are IMMUTABLE.
every call to conj, or anyother function returns a "new" object. To
optimize there is sharing of structure.
On Sun, Nov 23, 2008 at 4:38 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> 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.
>
>
> >
>
--
The Mafia way is that we pursue larger goals under the guise of
personal relationships.
Fisheye
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
