On 28 August 2013 11:50, Alan Busby wrote:
> On Wed, Aug 28, 2013 at 12:18 PM, guns 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 sent
On Wed 28 Aug 2013 at 12:50:19PM +0900, Alan Busby wrote:
> On Wed, Aug 28, 2013 at 12:18 PM, guns 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.
>
> Third, I'd
On Wed, Aug 28, 2013 at 12:18 PM, guns 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 back-end
implementa
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 sen
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 a
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 th
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
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 wrote:
> 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 th
On Tue, Aug 27, 2013 at 7:51 AM, Mike Anderson wrote:
> On 27 August 2013 20:45, Timothy Baldridge 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 i
+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
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 27
> 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* qui
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
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 the
On 27 August 2013 20:45, Timothy Baldridge 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 for this as i
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:
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, 201
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
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 wrote:
> My overall sense is that the convenience of using if-let directly in a few
> use cases doesn't justify making ch
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 wrote:
> My overall sense is that the convenience of using if-let directly in a few
>
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 s
On Fri, Aug 16, 2013 at 5:07 PM, Brandon Bloom wrote:
> > 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 flavour of drinks, which
> 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 4:50 PM, 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 /
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 /
> Hi all,
>
> I'm experimenting with core.async. Most of it
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 b
26 matches
Mail list logo
