If you use a singleton sentinel value that is generated privately within the core.async implementation, then the sentinel isn't really a regular "value" in the sense that it can be created by regular user code.
nil, on the other hand, gets used very frequently as a value in regular Clojure code. That's a key reason IMHO why it's better to use a sentinel as a closed channel indicator than nil. On Sunday, 18 August 2013 09:43:34 UTC+8, Ben wrote: > > A sentinel value also prevents channels from being able to send/receive > arbitrary values, without further wrapping. > > Sent from my iPhone > > On Aug 17, 2013, at 5:48 PM, Mikera <mike.r.an...@gmail.com <javascript:>> > wrote: > > My overall sense is that the convenience of using if-let directly in a few > use cases doesn't justify making channels fall short of being able to send > arbitrary values (nil specifically, and clearly boolean false can cause > some problems too). > > I think it would be a much better design to have a sentinel value and a > couple of specialised functions or macros that can detect / interact with > it appropriately. With a sentinel value the key part of your if-recv code > could just be something like: > > `(let [~name (<! ~port)] > (if (end-of-stream? ~name) > ~else > ~then)))) > > > I can see that wrappers for nil values could also work, but that seems to > be a more complex solution (and also potentially with more overhead) than a > sentinel value.... > > > On Saturday, 17 August 2013 07:50:06 UTC+8, Brandon Bloom wrote: > >> I ran into the other half of this problem: If you expect nils to signify >> closed channels, then you can't leverage the logically false nature of nil >> without excluding explicit boolean false values. Given the pleasant syntax >> of if-let / <! pairs, I reworked my early experiments to use if-recv >> which is defined as follows: >> >> (defmacro if-recv >> "Reads from port, binding to name. Evaluates the then block if the >> read was successful. Evaluates the else block if the port was closed." >> ([[name port :as binding] then] >> `(if-recv ~binding ~then nil)) >> ([[name port] then else] >> `(let [~name (<! ~port)] >> (if (nil? ~name) >> ~else >> ~then)))) >> >> >> I've considered some alternative core.async designs, such as an >> additional "done" sentinel value, or a pair of quote/unquote operators (see >> "reduced"), but nothing seems as simple as just avoiding booleans and nils, >> as annoying as that is. I'd be curious to here what Rich & team >> considered and how they're thinking about it. However, my expectation is >> that the nil approach won't change, since it's pretty much good enough. >> >> On Thursday, August 15, 2013 10:44:48 PM UTC-4, Mikera wrote: >>> >>> Hi all, >>> >>> I'm experimenting with core.async. Most of it is exceptionally good, but >>> bit I'm finding it *very* inconvenient that nil can't be sent over >>> channels. In particular, you can't pipe arbitrary Clojure sequences through >>> channels (since sequences can contain nils). >>> >>> I see this as a pretty big design flaw given the ubiquity of sequences >>> in Clojure code - it appears to imply that you can't easily compose >>> channels with generic sequence-handling code without some pretty ugly >>> special-case handling. >>> >>> Am I missing something? Is this a real problem for others too? >>> >>> If it is a design flaw, can it be fixed before the API gets locked down? >>> >> -- > -- > 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 <javascript:> > 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 <javascript:> > 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 <javascript:>. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- 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/groups/opt_out.
