On Fri, Aug 16, 2013 at 4:50 PM, Brandon Bloom <brandon.d.bl...@gmail.com>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. > One possibility is to retain nil as "closed" and have every other value come wrapped in a Just or Some-like constructor, which an if-recv macro would unwrap transparently, something like: (defmacro if-recv [[name port] then else] `(let [~name (<! ~port)] (if (nil? ~name) ~else (let [~name (unwrap ~name)] ~then)))) That would enable sending of nils, since on the far side they'd be wrapped. -- Ben Wolfson "Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure." [Larousse, "Drink" entry] -- -- 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.