On Thursday, October 29, 2015 at 5:05:04 AM UTC-5, Derek Troy-West wrote: > > Hi Alex, thanks for your efforts and the update. > > I have a few questions about promise-chan if you have a moment. > > Firstly, why provide promise-chan rather than requiring (chan > (buffers/promise)). The buffer provides the promise semantics and we don't > similarly have sliding-chan, dropping-chan, etc. Is this an effort to > delineate channels with promise-buffers from the vanilla variety? >
You should consider the promise buffer to be an implementation detail. There are multiple ways to implement a promise channel and in the future it's possible the implementation might change to using a custom channel implementation instead. The feature we are providing here is the promise channel and that's reflected in the api. > Secondly, I've perhaps mistakenly considered channels more as a conduit > between processes rather than a replacement for single assignment message > passing. I get the value of using a channel and the core.async state > machine for achieving promise-like semantics in a non-blocking way, and I > can achieve that for a single consumer with a normal channel, the rub is > this new buffer allows repeated consumption of a single value, and my > previous understanding of channel semantics 'a channel will return nil when > it is closed after some number of takes' no longer holds in all cases, > because a promise-buffer is never exhausted. > Nothing about channels guarantees they will be closed after some number of takes, so I disagree with this definition. > Practically I'm sure I'll always be aware of the buffer-flavour of a > channel that I'm using, but now we have a variety of channels for which > many channel operations do not make sense, i.e.: > > (async/go > (prn "result" (async/<! (async/into [] some-chan))) > > Am I right in suggesting a promise-channel is not really a channel, it's a > promise masquerading as a channel because of the value of having the state > machine as the mechanism of resolving assignment. This is clearly a welcome > addition, perhaps my understanding of channel semantics needs an upgrade. > The promise channel fulfills the channel api, so as far as I'm concerned, it is a channel (but one with special properties). I should have mentioned that promise-chan, offer!, and poll! were discussed by Rich at last year's Conj talk if anyone is interested in hearing him talk about these: https://youtu.be/4KqUvG8HPYo?t=52m6s Alex -- 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.
