Re: Microsoft Rx -style operations with core.async

2013-07-02 Thread Brandon Bloom
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

Re: Microsoft Rx -style operations with core.async

2013-07-02 Thread Brandon Bloom
> 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

Re: Microsoft Rx -style operations with core.async

2013-07-02 Thread Timothy Baldridge
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

Re: Microsoft Rx -style operations with core.async

2013-07-02 Thread Brandon Bloom
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

Re: Microsoft Rx -style operations with core.async

2013-06-30 Thread Brandon Bloom
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

Re: Microsoft Rx -style operations with core.async

2013-06-30 Thread David Nolen
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

Re: Microsoft Rx -style operations with core.async

2013-06-30 Thread Brandon Bloom
> 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.

Re: Microsoft Rx -style operations with core.async

2013-06-30 Thread David Nolen
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

Re: Microsoft Rx -style operations with core.async

2013-06-30 Thread Ben Wolfson
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

Re: Microsoft Rx -style operations with core.async

2013-06-30 Thread David Pollak
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

Re: Microsoft Rx -style operations with core.async

2013-06-30 Thread Brandon Bloom
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,

Re: Microsoft Rx -style operations with core.async

2013-06-30 Thread Brandon Bloom
> 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

Re: Microsoft Rx -style operations with core.async

2013-06-30 Thread Ben Wolfson
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))

Microsoft Rx -style operations with core.async

2013-06-30 Thread Brandon Bloom
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