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 > <javascript:_e(%7B%7D,'cvml','gary.verhae...@gmail.com');>> wrote: > >> Have you considered returning a lazy seq of events? >> >> >> On Tuesday, 2 June 2015, Christopher Small <metasoar...@gmail.com >> <javascript:_e(%7B%7D,'cvml','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 >> <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 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 >> <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 > <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.
