On Thu, May 20, 2010 at 10:40 AM, Rasmus Svensson <r...@lysator.liu.se> wrote:
> 2010/5/10 Anders Rune Jensen <anders.rune.jen...@gmail.com>
>>
>> [...] But I was a little surprised to find out that by
>> default, if you don't return anything, it will set the value of the
>> agent to nil. [...]
>
> Firstly, all clojure functions always return something. Some forms, such as
> 'cond' and 'when', return nil as a default value. So yes, the new state of
> the agent will be nil, since nil is the there-is-no-value value.
Yes. I'm just saying that it leads to not-very-pretty code.
> This is my understanding of agents: Agents, like their cousins var, atom and
> ref, is a way of handling state change. The 'send' and 'send-off' functions
> are very much like the 'swap!' of atoms and 'alter' of refs in that they
> take a state transition function, that when given the current state yields
> the next state. Only in this case, the state transition happens
> asynchronously in another thread. The points is that agents are a mechanism
> for managing state change.
>
> When using agents simply for the purpose of executing code in another
> thread, one could also use 'future'. Even though the name suggests that one
> has the option to fetch the result of the future expression later on, one
> doesn't have to. 'future' is equally fitted for
> run-in-another-thread-and-forget usage.
The only thing I'm trying to do is to make a macro that makes it
easier (meaning in this case: better code and less bugs) to use
agents. Nothing else.
I think an example is in place, this is probably a bad example but
should illustrate the point:
state:
:value 11
:message "no danger"
The algorithm:
(defn change-state [cur-state]
(when (> (:value cur-state) 10)
(assoc cur-state :message "danger, danger")))
How I'd have to write it when using an agent:
(defn change-state [cur-state]
(cond (> (:value cur-state) 10)
(assoc cur-state :message "danger, danger")
:else cur-state))
This is a trivial example, but once you have a more complex
state-change this "having-to-remember-to-cover-all-branches" gets
quite bothersome.
> // raek
>
> --
> 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
--
Anders Rune Jensen
http://www.iola.dk
--
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
