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.
