While it's fresh in my mind, some quick thoughts:
(defn inc-all
> "increments every int received in the input channel"
> ([in]
> (let [out (chan)]
>(inc-all in out)
>out))
> ([in out]
> (go (while true
>(>! out (inc (
A) The first overload and second overload for this
> These look great!
Thanks!
> I would, however, avoid using go-as. [...snip...]
Yeah, David Nolen mentioned that in IRC. I was thinking something along the
lines of (go-as [c blah] ...) which would basically do (let [c (or blah
(chan))] ...)
Next time I get some extra cycles, I'll investigate w
These look great!
I would, however, avoid using go-as. In the JCSP example a style such as
this is prefered most of the time:
(defn inc-all
"increments every int received in the input channel"
([in]
(let [out (chan)]
(inc-all in out)
out))
([in out]
(go (while true
(>! ou
When I first wrote this code, I intentionally avoided any custom
syntactical sugar and worked as closely with the primitives as I could.
After a few days away, I've used fresh eyes to abstract and revamp. The new
code is *dramatically* cleaner and I only needed to introduce a few simple
and pre
Then maybe we need (go-as [c arg] ...)
On Sunday, June 30, 2013 8:15:45 PM UTC-4, David Nolen wrote:
>
> Because of blocking on read/write on unbuffered channels - users might
> need more flexibility.
>
>
> On Sun, Jun 30, 2013 at 8:13 PM, Brandon Bloom
>
> > wrote:
>
>> > My understanding with
Because of blocking on read/write on unbuffered channels - users might need
more flexibility.
On Sun, Jun 30, 2013 at 8:13 PM, Brandon Bloom wrote:
> > My understanding with some member of the core.async team is that most
> channel based APIs fns should *take* a channel and only construct one as
> My understanding with some member of the core.async team is that most
channel based APIs fns should *take* a channel and only construct one as a
default.
Could you elaborate on and motivate that?
--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
On Sun, Jun 30, 2013 at 7:46 PM, Brandon Bloom wrote:
> Two bits of core.async feedback:
>
> 1) The (let [c chan] (go ...) c) pattern is *extremely-common*. Might be
> nice to have something like (go-as c ...) that expands to that pattern.
>
My understanding with some member of the core.async tea
On Sun, Jun 30, 2013 at 4:46 PM, Brandon Bloom wrote:
>
> 2) It's somewhat annoying to always have to consider boolean false all the
> time. Since nil signifies a closed channel, if, when, if-let, and when-let
> are extremely convenient. Unfortunately, they are subtly bugged! You need
> nil? check
On Mon, Jul 1, 2013 at 7:46 AM, Brandon Bloom wrote:
> Two bits of core.async feedback:
>
> 1) The (let [c chan] (go ...) c) pattern is *extremely-common*. Might be
> nice to have something like (go-as c ...) that expands to that pattern.
>
> 2) It's somewhat annoying to always have to consider bo
Two bits of core.async feedback:
1) The (let [c chan] (go ...) c) pattern is *extremely-common*. Might be
nice to have something like (go-as c ...) that expands to that pattern.
2) It's somewhat annoying to always have to consider boolean false all the
time. Since nil signifies a closed channel,
> I don't know the semantics of the MS functions so maybe this mirrors them
This code is not an attempt to replicate the semantics of Rx, just provide
a comparable set of operators.
> the implementations of take-while and drop-while remove an "extra"
element from the argument channel, right?
Yes
I don't know the semantics of the MS functions so maybe this mirrors them,
but the implementations of take-while and drop-while remove an "extra"
element from the argument channel, right?
user> (def c (chan))
#'user/c
user> (go (doseq [i (range 10)] (>! c i)))
#
user> (def d (take-while even? c))
Hi all,
Today, primarily for my own edification, I've been implementing as many
Microsoft Reactive Extensions operators as I can using core.async. The
results have been *spectacular*. core.async is an absolute pleasure to work
with. I'm so happy with how they have turned out, that I really want
14 matches
Mail list logo