Re: Do (should?) these core.async utilities exist?

2013-11-12 Thread Leon Grapenthin
Hi Paul,
 I have implemented at least the doseq equivalent in a library of my own 
called state-node: https://github.com/lgrapenthin/state-node.
It implements gochan and gochan-and. gochan lets you bind a binding-form to 
a channel but also lets you recur (if you bind things aside from the 
channel). It terminates the loop when the channel is closed. With 
gochan-and you can specify one form that will be evaluated after the 
channel is closed (e. g. close a target channel). 

E. g.:
(gochan-and (close! out-chan)
  [taken-val in-chan]
  (println "Value read from in-chan:" taken-val)
  (>! out-chan taken-val))

Please feel free to copy the macro directly from the library if you have 
any use for it :)

Maybe also have a look at reducep-hidden (adapted from hidden automatons 
from ELM) which kinda lets you do the same if you aren't going for 
side-effects or custom looping conditions. 

One problem with the lazy-sequence thing would be that such sequences would 
only work in go-blocks if I my thinking is right this morning.

Best regards, Leon.
 

On Tuesday, November 12, 2013 11:48:09 AM UTC+1, Paul Butcher wrote:
>
> I've been playing with core.async, and have come across a couple of things 
> that it seemed would probably be common use cases, but can't find anything 
> in the library that addresses them.
>
> I'd be grateful for pointers if any of these do exist and I'm just missing 
> them, or suggestions for reasons why I don't really want them and should be 
> tackling the problem in a different way:
>
>
>- A way to convert a channel to a lazy sequence (i.e. build the 
>sequence by repeatedly reading from a channel until it's closed). It seems 
>odd that core.async provides a means to turn a lazy sequence into a 
> channel 
>(to-chan) but not the inverse?
>- An equivalent of doseq for a channel, which repeatedly reads from 
>the channel and calls its body with the result of doing so, terminating 
>when the channel is closed.
>
>
> Of course, both of these are easy enough to write, but I'm wondering 
> whether the fact that they aren't provided as standard is telling me 
> something?
>
> --
> paul.butcher->msgCount++
>
> Silverstone, Brands Hatch, Donington Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> Skype: paulrabutcher
>
>
>
>  
>

-- 
-- 
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.


Re: Do (should?) these core.async utilities exist?

2013-11-12 Thread Gary Zhao
I think the whole idea is event-driven and async. 

On Tuesday, November 12, 2013 3:11:50 PM UTC-8, stuart@gmail.com wrote:
>
> Hi Paul,
>
> Two different reasons:  The channel-to-sequence conversion seems like a 
> questionable idea, making seqs that block.  The doseq over a channel is 
> easily enough implemented, and was not considered important enough to be on 
> the core API.
>
> Stu
>
>
> On Tue, Nov 12, 2013 at 4:48 AM, Paul Butcher 
> 
> > wrote:
>
>> I've been playing with core.async, and have come across a couple of 
>> things that it seemed would probably be common use cases, but can't find 
>> anything in the library that addresses them.
>>
>> I'd be grateful for pointers if any of these do exist and I'm just 
>> missing them, or suggestions for reasons why I don't really want them and 
>> should be tackling the problem in a different way:
>>
>>
>>- A way to convert a channel to a lazy sequence (i.e. build the 
>>sequence by repeatedly reading from a channel until it's closed). It 
>> seems 
>>odd that core.async provides a means to turn a lazy sequence into a 
>> channel 
>>(to-chan) but not the inverse? 
>>- An equivalent of doseq for a channel, which repeatedly reads from 
>>the channel and calls its body with the result of doing so, terminating 
>>when the channel is closed.
>>
>>
>> Of course, both of these are easy enough to write, but I'm wondering 
>> whether the fact that they aren't provided as standard is telling me 
>> something?
>>
>>  --
>> paul.butcher->msgCount++
>>
>> Silverstone, Brands Hatch, Donington Park...
>> Who says I have a one track mind?
>>
>> http://www.paulbutcher.com/
>> LinkedIn: http://www.linkedin.com/in/paulbutcher
>> Skype: paulrabutcher
>>
>>
>>
>>  
>>  -- 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@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.


Re: Do (should?) these core.async utilities exist?

2013-11-12 Thread Stuart Halloway
Hi Paul,

Two different reasons:  The channel-to-sequence conversion seems like a
questionable idea, making seqs that block.  The doseq over a channel is
easily enough implemented, and was not considered important enough to be on
the core API.

Stu


On Tue, Nov 12, 2013 at 4:48 AM, Paul Butcher  wrote:

> I've been playing with core.async, and have come across a couple of things
> that it seemed would probably be common use cases, but can't find anything
> in the library that addresses them.
>
> I'd be grateful for pointers if any of these do exist and I'm just missing
> them, or suggestions for reasons why I don't really want them and should be
> tackling the problem in a different way:
>
>
>- A way to convert a channel to a lazy sequence (i.e. build the
>sequence by repeatedly reading from a channel until it's closed). It seems
>odd that core.async provides a means to turn a lazy sequence into a channel
>(to-chan) but not the inverse?
>- An equivalent of doseq for a channel, which repeatedly reads from
>the channel and calls its body with the result of doing so, terminating
>when the channel is closed.
>
>
> Of course, both of these are easy enough to write, but I'm wondering
> whether the fact that they aren't provided as standard is telling me
> something?
>
> --
> paul.butcher->msgCount++
>
> Silverstone, Brands Hatch, Donington Park...
> Who says I have a one track mind?
>
> http://www.paulbutcher.com/
> LinkedIn: http://www.linkedin.com/in/paulbutcher
> Skype: paulrabutcher
>
>
>
>
>  --
> --
> 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.


Do (should?) these core.async utilities exist?

2013-11-12 Thread Paul Butcher
I've been playing with core.async, and have come across a couple of things that 
it seemed would probably be common use cases, but can't find anything in the 
library that addresses them.

I'd be grateful for pointers if any of these do exist and I'm just missing 
them, or suggestions for reasons why I don't really want them and should be 
tackling the problem in a different way:

A way to convert a channel to a lazy sequence (i.e. build the sequence by 
repeatedly reading from a channel until it's closed). It seems odd that 
core.async provides a means to turn a lazy sequence into a channel (to-chan) 
but not the inverse?
An equivalent of doseq for a channel, which repeatedly reads from the channel 
and calls its body with the result of doing so, terminating when the channel is 
closed.

Of course, both of these are easy enough to write, but I'm wondering whether 
the fact that they aren't provided as standard is telling me something?

--
paul.butcher->msgCount++

Silverstone, Brands Hatch, Donington Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
Skype: paulrabutcher




-- 
-- 
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.