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.anderson...@gmail.com> 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 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. -- -- 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.
