This is a often asked question, but one I think requires a bit of thought.
The key to solving this kind of issue in your code is to think of channel
ops as "io" and as side-effecting. It's tempting to stick these operations
deep inside nested functions, but I think that's rather "un-functional",
and "un-clojureish". In pure functional programming we try to keep the io
at the edges.
So this is the pattern I try to follow when writing core.async code: keep
the core functionally pure, and the side effects to the edges. This has
several nice side effects:

1) Your functionally pure code is now much easier to test, you can rip off
the core.async specific bits and test the core synchronously.

2) Your inputs and outputs are now in a single place, and so are easier to
reason about.

As mentioned above, you can still wrap function bodies in gos, if needed.
And you can use core.async/put! and take! from anywhere in your code. But I
do recommend trying to avoid jumping to these by default.

That being said, creating gos is quite cheap. On my MBP, after the JIT has
warmed up, I'm estimating the CPU cost of creating a go is about 140ns
(yes, ns). So creating them may not be the bottleneck they seem to be at
first. (and take that number with a big grain of salt).

Just some points to ponder.

Timothy Baldridge


On Mon, Jan 13, 2014 at 6:05 PM, t x <txrev...@gmail.com> wrote:

> Hi Stephen,
>
>   I now understand what you meant. Thanks writing a minimal test case.
>
>
> On Mon, Jan 13, 2014 at 3:34 PM, Stephen Cagle <same...@gmail.com> wrote:
>
>> And already, I see that the first one should have been
>>
>> (defn test []
>>    (async/go
>>      (println (async/<! (foo)))))
>>
>> Boy I wish you could edit this post after the fact.
>>
>> On Monday, January 13, 2014 3:32:39 PM UTC-8, Stephen Cagle wrote:
>>>
>>> I just want to re-iterate that there are many (some are probably better)
>>> ways to do this, but using what I suggested above it would be:
>>>
>>> (defn foo []
>>>   (async/go "hi"))
>>>
>>> (defn test []
>>>    (println (async/<! (foo))))
>>>
>>> (defn test []
>>>   (let [c (async/chan 10)]
>>>     (async/go
>>>      (async/>! c (async/<! (foo)))
>>>      (println (<! c)))))
>>>
>>> (test)
>>>
>>> I wrote the first (test) minimally as you aren't really doing anything
>>> with your 10 slot buffer. However, in real code maybe you are, so I tried
>>> to write the second (test) in the fashion that you wrote it.
>>>
>>> There is nothing really to what I am saying other than that, yes, the
>>> core.async codewalker cannot see into code that you call into. Therefore,
>>> if the code you call into also needs to do asynchronous things, you need to
>>> wrap it in something like a go block as well. With the above solution you
>>> might have 2 go machines "live" at the same time (the test and the foo go
>>> machines).
>>>
>>> In short, you have a trade-off here. If you want to modularize your code
>>> at the function (go machine) level, you are going to potentially have
>>> multiple go machines "live" at the same time.
>>>
>>> I don't have an editor/compiler on this tablet, so apologies for any
>>> silly errors.
>>>
>>  --
>> --
>> 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.
>>
>
>  --
> --
> 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.

Reply via email to