On 04.02.2009, at 15:03, MikeM wrote:
> This seems less burdensome - fewer cases where I'd need to do this vs
> (if (seq s) ...
A slightly off-topic comment: I wonder why the (if (seq s)...) idiom
is so important. It is completely unintellegible to a reader who is
not aware of the idiomatic
On Feb 4, 9:19 am, Konrad Hinsen wrote:
> On 04.02.2009, at 14:03, Rich Hickey wrote:
>
> > 1) Resource management in lazy contexts
> > 2) Memory consumption in recursive lazy contexts (the filter retains
> > skipped range issue)
> > 3) Full laziness in I/O and other side-effect contexts, and f
On 04.02.2009, at 14:03, Rich Hickey wrote:
> 1) Resource management in lazy contexts
> 2) Memory consumption in recursive lazy contexts (the filter retains
> skipped range issue)
> 3) Full laziness in I/O and other side-effect contexts, and for ease
> of understanding
> 4) Performance/elegance
On Feb 4, 9:03 am, MikeM wrote:
> > (if [] true false)
>
> > I'd hate to lose the ability to distinguish between an empty
> > collection and nothing.
>
> As a trade-off to allow nil-punning, you could stipulate the use of
> coll? in the above situation:
> (if (coll? []) true false) => true
> Th
>
> (if [] true false)
>
> I'd hate to lose the ability to distinguish between an empty
> collection and nothing.
>
As a trade-off to allow nil-punning, you could stipulate the use of
coll? in the above situation:
(if (coll? []) true false) => true
This seems less burdensome - fewer cases where I
On Feb 4, 6:55 am, Frantisek Sodomka wrote:
> Streams were also intended for I/O. Is lazier addition also able to
> cope with I/O successfully?
Yes. After full laziness, most of the issues with I/O have to deal
with resource management, which I plan to deal with a la carte with
the scope const
On Feb 4, 7:21 am, MikeM wrote:
> > Other than that, there is just the general loss of nil-punning. This
> > was the theoretical problem that kept me from making this tradeoff
> > earlier. I'm very much interesting in hearing from those for whom the
> > lazy branch represents a real problem due
On Feb 4, 1:45 am, Mark Engelberg wrote:
> One thing I couldn't tell from the "lazier" doc is whether rest is
> only being kept around for backward compatibility or whether there
> still might be reasons to actively prefer rest to more.
rest is being kept for compatibility and ease of use. It
>
> Other than that, there is just the general loss of nil-punning. This
> was the theoretical problem that kept me from making this tradeoff
> earlier. I'm very much interesting in hearing from those for whom the
> lazy branch represents a real problem due to loss of nil punning.
>
To preserve n
Streams were also intended for I/O. Is lazier addition also able to
cope with I/O sucessfully?
Can we have both - streams and lazy-seq?
My thought about streams is that if they get included, they could be
looked at as unsafe operations in Java/C# or unchecked math operations
- as long as programm
One thing I couldn't tell from the "lazier" doc is whether rest is
only being kept around for backward compatibility or whether there
still might be reasons to actively prefer rest to more.
--~--~-~--~~~---~--~~
You received this message because you are subscribed
On Feb 3, 9:57 pm, MikeM wrote:
> Code written with the fully-lazy branch certainly looks cleaner than
> the streams branch equivalent, and having full laziness seems like a
> plus. The local-clearing mechanism seems like it will be
> straightforward to use.
>
> Seems like this is the way to go
Code written with the fully-lazy branch certainly looks cleaner than
the streams branch equivalent, and having full laziness seems like a
plus. The local-clearing mechanism seems like it will be
straightforward to use.
Seems like this is the way to go. Are there any drawbacks?
--~--~-~
On Feb 3, 2009, at 15:31, Rich Hickey wrote:
> I've started documenting the lazy branch work here:
>
> http://clojure.org/lazier
Interesting stuff...
I agree that streams are ugly. Anything that will have most of the
advantages of streams while not enforcing explicit state management
(as st
Rich,
I like the way that's headed. I'm working on an network app where I'm
parsing a stream from a TCP socket. Being able to get the chars from
the socket in a lazy way, without reading one too many, would be
great. I fudged that by defining a function to read a single char
from the socket's
On Feb 2, 2:27 pm, Chouser wrote:
> On Mon, Feb 2, 2009 at 2:05 PM, MikeM wrote:
>
> > There is a "lazy" branch in SVN. The "streams" branch has been
> > discussed, but I haven't seen any discussion of the "lazy" branch -
> > perhaps I missed it.
>
> Here's a discussion from earlier today, mai
On Mon, Feb 2, 2009 at 2:05 PM, MikeM wrote:
>
> There is a "lazy" branch in SVN. The "streams" branch has been
> discussed, but I haven't seen any discussion of the "lazy" branch -
> perhaps I missed it.
Here's a discussion from earlier today, mainly about the "lazy" branch:
http://clojure-log
There is a "lazy" branch in SVN. The "streams" branch has been
discussed, but I haven't seen any discussion of the "lazy" branch -
perhaps I missed it. Rich and/or other contributors if you have a
little time - I'm curious what changes are being considered and when
these might show up in trunk. Al
18 matches
Mail list logo
