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.

Reply via email to