That makes sense. Thanks for the explanation. On Tuesday, 2 June 2015, Timothy Baldridge <tbaldri...@gmail.com> wrote:
> I think the problem is more centered around push vs pull based APIs. > Callbacks, and core.async work quite well for push based apis (e.g. event > streams). Lazy seqs work on a pull basis. ZeroMQ has a pull API, so lazy > seqs work quite well there. > > Also lazy-seqs aren't async. If you call (next ..) and the computation of > the next cell makes a network request, you've now blocked the current > thread waiting for a response. > > Timothy > > On Tue, Jun 2, 2015 at 10:15 AM, Gary Verhaegen <gary.verhae...@gmail.com > <javascript:_e(%7B%7D,'cvml','gary.verhae...@gmail.com');>> wrote: > >> I'm not sure I follow why lazyness cannot be asynchronous, as long as >> reads are blocking (which they are by default in core.async, I believe). >> Your description of the problem made me think of this blog post I read >> some years ago: >> >> http://oobaloo.co.uk/clojure-abstraction-and-zeromq >> >> which explains how to expose a stream of zeromq messages as a lazy seq, >> so that consuming code does not need to know about zeromq. It sounded >> similar, but maybe it's not. >> >> >> On Tuesday, 2 June 2015, Christopher Small <metasoar...@gmail.com >> <javascript:_e(%7B%7D,'cvml','metasoar...@gmail.com');>> wrote: >> >>> Lazy seqs by themselves wouldn't work, since it needs to be >>> asynchronous, and it's always possible that when you ask for the next >>> element, that there won't have been any new events yet. I suppose that you >>> could return a lazy sequence of futures, which is interesting, but not >>> particularly idiomatic. At that point I'd rather just use core.async, >>> because that's what it starts to look like. >>> >>> On Tue, Jun 2, 2015 at 1:19 AM, Gary Verhaegen <gary.verhae...@gmail.com >>> > wrote: >>> >>>> Have you considered returning a lazy seq of events? >>>> >>>> >>>> On Tuesday, 2 June 2015, Christopher Small <metasoar...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> Lots of great thoughts here; thanks so much for the feedback! >>>>> >>>>> It seems the general opinion so far leans towards keeping things >>>>> simple. I definitely resonate with this statement: "having to write >>>>> some glue code feels less frustrating than when libs make assumptions >>>>> that I don't like." >>>>> >>>>> Unfortunately, the abstractness of my question is allowing things to >>>>> drift a little further than I intended. So to ground things a bit, in my >>>>> particular use case promises wouldn't work because I need to allow for a >>>>> stream of events. Promises only let you capture a single event. >>>>> >>>>> Additionally, I feel it worth responding to some of Timothy's comments >>>>> about the difficulty of getting a core.async centric API "right". While I >>>>> agree that in general (and particular with more complicated APIs) getting >>>>> things right can be tricky, the situation I'm dealing with (I think) can >>>>> be >>>>> dealt with quite simply. Imagine a stream of events coming in from The >>>>> Real >>>>> World (TM), and that we'd like to process somehow. The solution I've been >>>>> chewing on is a function that let's us specify a single channel on which >>>>> events should be placed. The nice thing about this is that it assumes >>>>> almost nothing about how you'll use core.async, only that you'll be using >>>>> it. You can decide whether you want a buffer or not, whether it should >>>>> drop >>>>> or slide or block/park, whether it should be tapped, etc. >>>>> >>>>> The potentially nice thing about core.async for this use case over >>>>> callbacks (as far as the implementation is concerned) is that should we >>>>> decide to stop listening to events, we can just close! the channel. This >>>>> can then serve as a signal to the underlying code/process actually reading >>>>> in events that it can stop. With callbacks, it will probably be necessary >>>>> to have something that manages these processes and listens for kill >>>>> signals, potentially complicating things quite a bit. (It's possible there >>>>> is an elegant solution here, and I haven't thought about it too much yet, >>>>> but this is my current intuition...) >>>>> >>>>> I should also mention that Manifold did come to mind for this project, >>>>> and it's something I'll probably look at and consider again. Thanks for >>>>> bringing it up. >>>>> >>>>> Please continue to share your thoughts given all this :-) >>>>> >>>>> With gratitude >>>>> >>>>> Chris >>>>> >>>>> >>>>> >>>>> On Monday, June 1, 2015 at 10:18:46 PM UTC-7, Leonardo Borges wrote: >>>>>> >>>>>> For people interested in using the 'futures' approach, this might be >>>>>> of interest: https://github.com/leonardoborges/imminent >>>>>> >>>>>> >>>>>> It's a library that implements composable futures for Clojure on top >>>>>> of JVM's ForkJoin framework. It allows you to attach callbacks as well as >>>>>> apply combinators such as map etc... >>>>>> >>>>>> >>>>>> On 2 Jun 2015 3:04 pm, "Timothy Baldridge" <tbald...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> The problem with futures is that you can't attach callbacks to them, >>>>>>> you can only block a thread waiting on them. So futures interface quite >>>>>>> poorly with async libraries, hence the reason core.async was created in >>>>>>> the >>>>>>> first place. >>>>>>> >>>>>>> Core.async is a dependency, but it's hardly one that changes fast. >>>>>>> The last breaking change was about a year and a half ago (Jan 2014). >>>>>>> Besides that, all changes are additional "opt-in" features. That's a lot >>>>>>> less change than most libraries in the Clojure ecosystem. >>>>>>> >>>>>>> Timothy >>>>>>> >>>>>>> On Mon, Jun 1, 2015 at 10:42 PM, Stanislav Yurin <jus...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> As for the core.async, I think it is too personal and has too much >>>>>>>> raw power, to be all that restricted in some logical bottleneck upon >>>>>>>> results return from the third-party lib. >>>>>>>> Not counting the fact it is a (a) dependency that (b) changes fast. >>>>>>>> >>>>>>>> On Monday, June 1, 2015 at 10:18:19 PM UTC+3, Christopher Small >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Greetings >>>>>>>>> >>>>>>>>> I imagine most of us here would rather use core.async channels >>>>>>>>> over callbacks in their application code, particularly with more >>>>>>>>> complicated applications. But is it okay/preferable for Clojure >>>>>>>>> libraries >>>>>>>>> to force their users to use core.async channels as part of an API (an >>>>>>>>> event >>>>>>>>> channel, for example)? >>>>>>>>> >>>>>>>>> As much as I love core.async, I can't help but wonder whether >>>>>>>>> sticking with callbacks for an API isn't a simpler/better design >>>>>>>>> strategy. >>>>>>>>> It's easy enough to drop messages on a channel in a callback, and this >>>>>>>>> let's users opt-in. But if one expects core.async channels are what >>>>>>>>> most >>>>>>>>> would prefer anyway, is it okay to foist them upon everyone? >>>>>>>>> >>>>>>>>> As a follow up, does your opinion on the matter change if >>>>>>>>> implementations of an API become simpler using core.async channels? >>>>>>>>> >>>>>>>>> >>>>>>>>> Looking forward to your thoughts :-) >>>>>>>>> >>>>>>>>> Chris Small >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> PS I'm asking because I'm working on a physical computing API ( >>>>>>>>> https://github.com/clj-bots/pin-ctrl) and debating between using >>>>>>>>> channels vs callbacks for the edge detection functionality (if you're >>>>>>>>> not >>>>>>>>> familiar, edge detection let's you asynchronously handle changes in >>>>>>>>> pin >>>>>>>>> state, such as button pushes). If you're interested in this question >>>>>>>>> as it >>>>>>>>> applies specifically to this application, feel free to join the >>>>>>>>> discussion >>>>>>>>> on our gitter channel: https://gitter.im/clj-bots/chat >>>>>>>>> >>>>>>>> -- >>>>>>>> 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. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> “One of the main causes of the fall of the Roman Empire was >>>>>>> that–lacking zero–they had no way to indicate successful termination of >>>>>>> their C programs.” >>>>>>> (Robert Firth) >>>>>>> >>>>>>> -- >>>>>>> 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 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. >>>>> >>>> -- >>>> 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 a topic in the >>>> Google Groups "Clojure" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/clojure/nuy2CAA89sI/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> clojure+unsubscr...@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 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. >>> >> -- >> 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 >> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 >> <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@googlegroups.com');>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > 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 > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 > <javascript:_e(%7B%7D,'cvml','clojure%2bunsubscr...@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 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.
