Thanks Alex, I think I can sum up my confusion as: I thought channels were single take, but understand now that is not necessarily the case.
In his 2013 Strange Loop talk Rich described first-class channels and the subset of state that they expose: "But I think what's really cool about first class channels is that they expose a subset of state, and it's a very interesting and far safer one, which I'll call flow state, right, which is just about all you can do with this kind of state is put stuff in it, and then you really don't know anything more about it. Or you can take stuff out of it, and you really don't know how it got there." In particular he drew an analogy that really resonated with me, shared-state=coat-hook, flow-state=conveyor-belt. "It's going to go on a conveyor belt. It's going to, you know, somewhere else. It's going to go down that chute and you can't recover it. The UPS truck is going to drive away. And that's good because you can't possibly have your life depend on going back and seeing the same thing there again. So it's not really like state the way shared state and place oriented state is. Flow state is much simpler. It's much easier to reason about and much safer because you do not have this expectation of coming back" Understanding the limitations of analogies, does this new channel adhere to that concept of flow-state? Is it a conveyor-belt or a coat-hook? Apologies if the concept of what state a channel exposes has been updated since then and I've missed the point. I found that particular analogy a powerful one when trying to understand channels so perhaps that's why I'm hung up on it. - https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/CoreAsync.md On Fri, Oct 30, 2015 at 10:10 AM, Alex Miller <a...@puredanger.com> wrote: > To be clear, I didn't mean that a channel is guaranteed to be closed, >> rather that previously I could count on the ability to drain a channel >> after I have chosen to close it. Closing a promise-chan which has received >> a value has no impact on later takes, it is indistinguishable from a >> channel with an infinite buffer filled with a single value, which feels >> like a deviation from the thought that unbounded buffers are bad. The >> example in my previous message will OOM when used with a promise-chan. >> > > The buffer is not unbounded - it is of size 1. > > >> This new behaviour doesn't directly contradict the close! dosctring - >> "Data in the channel remains available for taking, until exhausted, after >> which takes will return nil", but that description could leave you with the >> expectation that data is exhausted. >> >> I guess I'm trying to understand if this new channel type is intended to >> be used with the battery of existing channel macros (pipe, reduce, >> pipeline, mult, etc.), where it may act as an unbounded, uncloseable >> producer of values, or if it's really only intended to be used as a promise >> which can be resolved in a non-blocking manner using put, take, >!, <!, >> !!>, !!<. >> > > It is primarily useful as a promise, but it can be useful to combine it > with other channel ops with alts etc. But there may be other use cases > where it's useful. > > >> If it's the latter, would it make sense to rename promise-chan to >> promise, i.e. a core.async promise type who's implementation happens to be >> a channel, and expand only those macros relating to puts and takes to >> accept chan-or-promise. >> > > We are not going to change the name - it is a channel with promise > semantics. > > -- > 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/NdQMUs1mTUU/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.
