I don't see a way for a reducing function to make its return value depend on the result of another callback.
On Monday, September 22, 2014 9:45:15 PM UTC+2, Wilker wrote: > > I understand Leon, but all that only applies on Java world... The issue > here is because I depend on async stuff, in Java you always have options to > do it sync, you don't need any of those callbacks at all, this is a JS API > issue. So in my case I really need the async factor here, I can't avoid it. > > Given that, would be possible to make transducers async? I think the big > deal of transducers is exactly don't having to re-write map, filter, etc... > That's why I'm really trying to get then to work on this situation, unless > someone knows for sure that its not possible, than I can accept the > limitations and keep all my custom versions that can handle async > processing... > > Thanks. > > --- > Wilker Lúcio > http://about.me/wilkerlucio/bio > Woboinc Consultant > +55 81 82556600 > > On Mon, Sep 22, 2014 at 4:22 PM, Leon Grapenthin <grapent...@gmail.com > <javascript:>> wrote: > >> 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> >>> 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 >>>> 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/d/optout. >>>> >>> >>> -- >> 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.
