What you are describing is a pub sub type system. This could be built on top of core.async, but it doesn't have to change the core library at all.
But yes, you are mis-understanding the main use-case for a library like core.async. The library was created to allow for the building of systems that consist of queues and workers that pull items from those queues. As Rich explained it a few times, consider an assembly plant. Workers take items from conveyor belts, perform some work and place them on other belts. In this use case, duplicating items and giving a copy to each worker doesn't make a whole lot of sense. Timothy On Tue, Sep 3, 2013 at 8:00 AM, bertschi <nils.bertschin...@googlemail.com>wrote: > Hi, > > recently I got interested core.async (also thanks to great blog post such > as the ones by David Nolen) and wanted to understand better how it compares > to other reactive libraries, in particular coming from the research on > Functional Reactive Programming (FRP). > > Compared to FRP, core.async appears to be build around side-effects on > channels which breaks referential transparency. What I mean here, is that > channels are somewhat like reference types and connect a (time varying) > value to an identity. > > As an example consider a map-like channel transformer (as found in many > posts explaining core.async) (map-ch f in out) which takes values x from > the input channel in and writes (f x) to the output channel out. > > (defn map-ch > ([f in] > (map-ch f in (chan))) > ([f in out] > (go (loop [] > (if-let [x (<! in)] > (do (>! out (f x)) > (recur)) > (close! out)))) > out)) > > Now, the following two snippets behave rather differently: > > (let [out-1 (map-ch inc (<some function creating a channel and writing > data to it>)) > out-2 (map-ch dec (<some function creating a channel and writing > data to it>))] > (go (loop [] > (when-let [x (<! out-1)] > (println "receiving " x) > (recur))))) > > (let [in (<some function creating a channel and writing data to it>) > out-1 (map-ch inc in) > out-2 (map-ch dec in)] > (go (loop [] > (when-let [x (<! out-1)] > (println "receiving " x) > (recur))))) > > Whereas the first example receives all incremented values, the second one > receives potentially less since both consumers read from the very same > input channel! This also means that one can break working code, by > (accidently) attaching an additional consumer ... note that in Rx I can > subscribe as many times as I want to an observable without any effect on > the rest of the data flow. > > Maybe I'm misunderstanding CSP and how it allows to compose and > synchronize processes, but somehow I feel that channels complect the idea > of state varying values and identity. Regarding that referential > transparency, which is required for equational reasoning, is one of the > best properties of purely functional programs, breaking it seems to be at > least problematic. > > Any thoughts? > > Nils > > -- > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
