Hi,
Am 31.01.2009 um 15:55 schrieb André Thieme:
On 31 Jan., 02:47, Jason Wolfe wrote:
I think this behavior is as-intended, although I agree that it is
confusing.
I am worried that you could be right.
That’s why I suggested to modify the doc string of lazy-cat.
In my opinion the real step
On 31 Jan., 02:47, Jason Wolfe wrote:
> I think this behavior is as-intended, although I agree that it is
> confusing.
I am worried that you could be right.
That’s why I suggested to modify the doc string of lazy-cat.
In my opinion the real step that needs to be done is to go away
from making ni
Ok, I take it back. (no pun intended)
I know that this used to be a problem, but looking through my email
history, it appears that the over-eager take was reported by Chouser,
and subsequently fixed by Rhickey.
On Sat, Jan 31, 2009 at 9:47 AM, André Thieme
wrote:
>
> On 31 Jan., 02:44, Daniel R
On 31 Jan., 02:44, Daniel Renfer wrote:
> user=> (take 0 (lazy-cat [(println 10)] [(println 20)]))
> 10
> nil
>
> What you see here is not an issue with lazy-cat, but rather an issue
> with take. The current implementation of take evaluates one more than
> the n passed to it.
I don’t think so:
On Jan 30, 5:44 pm, Daniel Renfer wrote:
> user=> (take 0 (lazy-cat [(println 10)] [(println 20)]))
> 10
> nil
>
> What you see here is not an issue with lazy-cat, but rather an issue
> with take. The current implementation of take evaluates one more than
> the n passed to it.
Hmm, I don't thi
I think this behavior is as-intended, although I agree that it is
confusing.
The reason for this stems from the fact that lazy-cat returns a seq,
and the only allowed representation for the empty seq is "nil" (i.e.,
Java null). Thus, lazy-cat must always do enough evaluation to know
whether to r
user=> (take 0 (lazy-cat [(println 10)] [(println 20)]))
10
nil
What you see here is not an issue with lazy-cat, but rather an issue
with take. The current implementation of take evaluates one more than
the n passed to it.
So in this case, 1 element of the seq is evaluated and "10" is printed.
Some minutes ago I found out that there is a mismatch between my
interpretation of lazy-cats docstring and the actual behaviour of that
macro.
Its docstring says:
"Expands to code which yields a lazy sequence of the concatenation
of the supplied colls. Each coll expr is not evaluated until it i
