On 23 Nov., 13:38, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:

> 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.

A typical design pattern in functional programming languages is,
to write ones own map function. Was it easier to solve your problem
by doing it with lists compared to something like:

user> (defn vmap [function vector]
        (loop [[f & r :as v] vector  result []]
          (if (nil? v)
              result
              (recur r (conj result (function f))))))
#'user/vmap
user> (vmap inc [10 20 30])
[11 21 31]
?

Although I would agree that something like vmap should be in the
core language itself. Maybe if there would be a datatype
clojure.lang.LazyConj vs. the now existing clojure.lang.LazyCons.
And then a (lazy-conj ...) function would also be needed.
This could then build lazy lists and also vectors, and on top of that
one could build vmap, or replace map with it.


> 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.

I suppose this was done as it is slightly cheaper to cons up lists
than
inserting to the end of a vector, which is implemented as a tree under
the hood.
Perhaps Rich could step in here and tell us more.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to