On Fri, Aug 16, 2013 at 4:50 PM, Brandon Bloom <[email protected]>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 [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
