The steps of your transducer composition are depending on each other. They can only produce a result from an input if they process it synchronously. If you had <!! available and would use it as you have described, you would reenforce synchronous input processing: Once you would consume an item, the code would have the exact same blocking characteristics as if the functions were returning values instead of channels. You would have gained nothing for the cost of creating overhead.
On Monday, September 22, 2014 1:53:52 AM UTC+2, Wilker wrote: > > Because it's Node-JS environment, and that can be the same for any async > Javascript, you never wanna call sync operations (like sync ajax) because > they block everything... > > I was noticing that is a non-issue at all in Java world, since you can > always read blocking into the predicate, for example: (filter (comp <!! > my-chan-pred)) > > But in Javascript that's not possible since it can't support read blocking. > > --- > Wilker Lúcio > http://about.me/wilkerlucio/bio > Woboinc Consultant > +55 81 82556600 > > On Sun, Sep 21, 2014 at 8:50 PM, Leon Grapenthin <grapent...@gmail.com > <javascript:>> wrote: > >> Why would you want the the predicates and readdir to return channels? >> >> On Monday, September 22, 2014 12:14:27 AM UTC+2, Wilker wrote: >>> >>> Just an add, >>> >>> I was thinking if we could have something like a "deref" running during >>> the transducers, in order to enable value unwrapping (that way we could >>> handle channels/values in same fashion). I understand that is complicated >>> maybe because overhead, and also more tricky into JS world were you can't >>> deref a channel into a sync fashion. >>> >>> But the point remains, there is way to seamlessly handle async and sync >>> operations using the same transducers? Or something like it. >>> >>> Best regards. >>> >>> --- >>> Wilker Lúcio >>> http://about.me/wilkerlucio/bio >>> Woboinc Consultant >>> +55 81 82556600 >>> >>> On Sun, Sep 21, 2014 at 7:01 PM, Wilker <wilke...@gmail.com> wrote: >>> >>>> Hi guys, >>>> >>>> I'm playing with transducers here, and trying out stuff just for fun, >>>> there is something that I'm kind stuck on how to approach. I understand >>>> the >>>> great abstraction that transducers provide over don't carrying about the >>>> input source type, but I'm struggling to deal with async operations into >>>> my >>>> pipeline. >>>> >>>> For example, I'm working with Node.JS async API's for file system >>>> operations, I want to stick with the async versions since I don't wanna >>>> block the event loop of Node. >>>> >>>> So, let's say I have a source with ["dir", "other"] and I wanna create >>>> an operation that will simple filter which paths exists, are directories, >>>> and then list the `ls` of each remaining entry. >>>> >>>> So, I first created "channel returning" functions for the Node >>>> operations, I'll not put the code here because I don't think it's really >>>> relevant here, just consider that I have them. >>>> >>>> So, my pipeline would start looking something like this: >>>> >>>> (comp (filter exists?) >>>> (filter is-dir?) >>>> (mapcat readdir)) >>>> >>>> Of course, this doesn't works... Because `exists?`, `is-dir?` and >>>> `readdir`, all of them return channels, so the filter would always pass >>>> since a channel is always a valid value... The same applies to mapcat, it >>>> would try to concat into a channel... >>>> >>>> This is making me notice some barrier to be able to compose async >>>> operations with regular operations. >>>> >>>> Maybe would be possible to "sign" somehow operations to make then run >>>> async? >>>> >>>> The only viable option that I've found is with pipeline-async, which >>>> accepts an async function, but that doesn't composes with the other >>>> operations (map, filter, drop-while...) >>>> >>>> Is there already a solution to that? Or maybe I'm just doing it wrong >>>> and there is a better way to handle those cases? >>>> >>>> I would love to know how you guys are handling those kind of situations. >>>> >>>> Thanks. >>>> >>>> --- >>>> Wilker Lúcio >>>> http://about.me/wilkerlucio/bio >>>> Woboinc Consultant >>>> +55 81 82556600 >>>> >>> >>> -- >> 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 >> <javascript:> >> 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 <javascript:> >> 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 <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/d/optout.
