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,
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:
On 27 August 2013 20:45, Timothy Baldridge tbaldri...@gmail.com wrote:
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
All your arguments come down to this:
I have an arbitrary seq of things I want to send down a channel. It's
exactly that concept I that I push against. Everything you've mentioned
thus far is a data structure. Channels are not data structures they are
concurrency management primitives, treat them
On Tue, Aug 27, 2013 at 10:51 AM, Mike Anderson
mike.r.anderson...@gmail.com wrote:
To me it's all about consistency with other Clojure constructs. You can
safely put nils in sequences, vectors, lists, sets etc.. nil is a valid
value just like anything else. So why can't you put them in a
In every use of channels I've had thus far, nil is better expressed as an
empty collection, false, 0, :tick, or some other ground value.
I agree completely. But I'll note that you mention false being useful...
If you're writing completely general operators, like map, which are
*sometimes* quite
Right, the use of false is a special case. I'm thinking of a mouse event
stream, may have a button channel that sends true or false based on the
state of the mouse button. Even saying that though, I would probably opt
for :clicked and :unclicked or somethig of that nature.
Timothy
On Tue, Aug
+1
We built a distributed software sending/receiving *messages* based on
different protocols.
All our protocols wrap data in an envelope. The receiver can then decide how to
handle the message based on the envelope. Obviously, nil makes a bad envelope.
A nil message on a channel never had any
On Tue, Aug 27, 2013 at 7:51 AM, Mike Anderson mike.r.anderson...@gmail.com
wrote:
On 27 August 2013 20:45, Timothy Baldridge tbaldri...@gmail.com wrote:
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
As long as we don't go full Haskell mode:
data Message a = Value a | Done
On Tue, Aug 27, 2013 at 11:20 AM, Timothy Baldridge tbaldri...@gmail.comwrote:
Right, the use of false is a special case. I'm thinking of a mouse event
stream, may have a button channel that sends true or false based
I still don't see why you would want to to arbitrarily limit what you can
put down a channel. FWIW, plenty of other concurrency management primitives
allow nils as values (java.util.concurrent.AtomicReference, Clojure atoms /
refs / agents to name but a few).
My motivating use case is the ability
On Wed 28 Aug 2013 at 09:38:06AM +0800, Mike Anderson wrote:
Of course, if anyone has an actual technical argument why it is
necessary/better to use nil as a sentinel value, I would be delighted to
learn of it and would consider myself enlightened.
Forgive me if someone already mentioned
Well, that's certainly a good explanation of why core.async works the way
it does now - it's a natural and sensible starting point to build on Java
Queues.
I don't think that this necessarily implies that we have to follow this
model in the future Clojure API though. The Java designers didn't
On Tue 27 Aug 2013 at 07:42:53PM -0700, Mikera wrote:
On Wednesday, 28 August 2013 09:54:51 UTC+8, guns wrote:
On Wed 28 Aug 2013 at 09:38:06AM +0800, Mike Anderson wrote:
Of course, if anyone has an actual technical argument why it is
necessary/better to use nil as a sentinel value,
On Wed, Aug 28, 2013 at 12:18 PM, guns s...@sungpae.com wrote:
Oh, I was confused; I was thinking about sentinel values in user code.
Yes, I imagine a single private (Object.) would work just fine, with
very little overhead.
First, I'd hope that sentinel values would be handled by the
On Wed 28 Aug 2013 at 12:50:19PM +0900, Alan Busby wrote:
On Wed, Aug 28, 2013 at 12:18 PM, guns s...@sungpae.com wrote:
Oh, I was confused; I was thinking about sentinel values in user
code. Yes, I imagine a single private (Object.) would work just
fine, with very little overhead.
On 28 August 2013 11:50, Alan Busby thebu...@gmail.com wrote:
On Wed, Aug 28, 2013 at 12:18 PM, guns s...@sungpae.com wrote:
Oh, I was confused; I was thinking about sentinel values in user code.
Yes, I imagine a single private (Object.) would work just fine, with
very little overhead.
If you use a singleton sentinel value that is generated privately within
the core.async implementation, then the sentinel isn't really a regular
value in the sense that it can be created by regular user code.
nil, on the other hand, gets used very frequently as a value in regular
Clojure code.
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
That's precisely the design followed by Magpie, described here:
http://journal.stuffwithstuff.com/2013/04/17/well-done/
Parts 1 2 of that series are worth reading too.
On Sat, Aug 17, 2013 at 8:48 PM, Mikera mike.r.anderson...@gmail.comwrote:
My overall sense is that the convenience of using
A sentinel value also prevents channels from being able to send/receive
arbitrary values, without further wrapping.
Sent from my iPhone
On Aug 17, 2013, at 5:48 PM, Mikera mike.r.anderson...@gmail.com wrote:
My overall sense is that the convenience of using if-let directly in a few
use
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
On Fri, Aug 16, 2013 at 4:50 PM, Brandon Bloom brandon.d.bl...@gmail.comwrote:
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
have every other value come wrapped in a Just or Some-like constructor
That's what I meant by a pair of quote/unquote operators
--
--
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
On Fri, Aug 16, 2013 at 5:07 PM, Brandon Bloom brandon.d.bl...@gmail.comwrote:
have every other value come wrapped in a Just or Some-like constructor
That's what I meant by a pair of quote/unquote operators
ah, gotcha
--
Ben Wolfson
Human kind has used its intelligence to vary the
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
26 matches
Mail list logo
