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. I don't know if there is an easy fix for this or not. I assume if there were, it would probably have been fixed by now. If this is indeed part of the desired effect of calling take and not just a side-effect of the current implementation, perhaps we need a warning on take that it is a tad too eager. I know this has bit myself and others on more than one occasion. On Fri, Jan 30, 2009 at 6:55 PM, André Thieme <splendidl...@googlemail.com> wrote: > > 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 is > needed." > > I would expect that in > (take 0 (lazy-cat [(println 10)] [(println 20)])) > no evaluation is needed. If lazy-cat were lazy it would return > immediately, > without concatenating anything. > > Maybe the docstring can get modified? > Although I personally see this current behaviour as not correct, while > the > docstring is right. > > > --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
