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