The reason for not allowing nils isn't a complex one, and basically boils
down to the following:
a) to avoid race conditions, we need a single value to signal "the channel
is closed". As mentioned, nil is the obvious choice for this as it matches
lazy seqs and fits well with the rest of clojure:
(when-let [v (<! c)]
(process v))
If we chose a different value, this becomes much more ugly:
(let [v (<! c)]
(when-not (= v :async/closed)
(process v)))
b) I question if there are any valid uses for putting nil in a channel.
With all due respect to all who have written here, thus far, every
complaint about nils and channels boils down to a conversion from seqs to
channels. This is the wrong way to look at the problem. Channels are
co-ordination primitives not data structures. Simply because a lazy seq
looks like a channel, doesn't mean that they should be treated as such.
In all the core.async code I've written I've never had to put a nil in a
channel, so I'm left with the uncomfortable conclusion that most complaints
on this subject are contrived. I could be wrong, but I just haven't seen a
valid use case yet.
This all being said, there really isn't a technical reason to not allow
nils, it just simplifies much of the design and that probably translates to
better performance. So the restriction could be lifted if a rock solid
reason could be found, but as of yet, I haven't seen it.
Timothy Baldridge
On Tue, Aug 27, 2013 at 2:12 AM, Max Penet <m...@qbits.cc> wrote:
> It's a real problem for me too, I also wonder what was the intention
> behind this. I guess there could be a very good reason for this special
> treatement of nils, but I haven't seen it yet.
>
> I would love to hear about this from people involved in core.async
> development.
>
> On Friday, August 16, 2013 4:44:48 AM UTC+2, 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.
>
--
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)
--
--
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.
