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.
