On Jun 12, 2009, at 7:52 PM, Wrexsoul wrote:
> Well, I did it. Made implementing lazy seqs that require stateful
> generator functions easy, that is:
>
> (defn files-and-dirs-recursive [dir]
> (super-lazy-seq [stack [(to-file dir)]]
>(if-not (empty? stack)
> (let
On Jun 15, 4:58 am, Wrexsoul wrote:
> Eh. That didn't occur to me. It could be combined with the meta-nil
> trick, too:
>
> (defn custom-lazy-seq [genfn]
> (map #(first %)
> (take-while (complement nil?)
> (repeatedly genfn
>
> where the genfn returns nil for no-next-item and [i
On Jun 14, 2009, at 12:53 PM, James Reeves wrote:
>
> On Jun 14, 6:32 pm, Wrexsoul wrote:
>> I wrote super-lazy-seq because repeatedly can't generate a finite
>> sequence. It just spat out
>>
>> (File1 File2 File3 File4 nil nil nil nil nil nil nil ...
>
&
On Jun 14, 2:53 pm, James Reeves wrote:
> On Jun 14, 6:32 pm, Wrexsoul wrote:
>
> > I wrote super-lazy-seq because repeatedly can't generate a finite
> > sequence. It just spat out
>
> > (File1 File2 File3 File4 nil nil nil nil nil nil nil ...
>
>
On Jun 14, 6:32 pm, Wrexsoul wrote:
> I wrote super-lazy-seq because repeatedly can't generate a finite
> sequence. It just spat out
>
> (File1 File2 File3 File4 nil nil nil nil nil nil nil ...
Well, you could wrap it in take-while:
(defn custom-lazy-seq [stream]
(take-
gt; For example:
>
> (defn custom-lazy-seq [stream]
> (repeatedly #(next-item-in-seq stream)))
I wrote super-lazy-seq because repeatedly can't generate a finite
sequence. It just spat out
(File1 File2 File3 File4 nil nil nil nil nil nil nil ...
:)
--~--~-~--~~-
ed, except by closing the initial stream.
> OK. Even so, the implementation in terms of super-lazy-seq shows the
> power of that macro. Mostly, I'm doing quite a few things with I/O
> that require custom next-item-in-seq generators for the records or
> other objects returned, for
ll
> leak a file handle.
That's a problem with lazy seqs and IO in general. You just need to be
careful.
IIRC Rich is working on a solution, though.
> > > Is file-seq recursive? I'd figured it just returned the flat contents
> > > of a directory.
>
> > Yep
le.
> > Is file-seq recursive? I'd figured it just returned the flat contents
> > of a directory.
>
> Yep, it's recursive.
OK. Even so, the implementation in terms of super-lazy-seq shows the
power of that macro. Mostly, I'm doing quite a few things with I/O
that require
On Jun 14, 3:21 am, Wrexsoul wrote:
> It lets you write the generator in a style similar to loop/recur, and
> generally in half the code. And, it demonstrates the kinds of things
> you can do with macros.
Ahh, I see. That could be useful under some circumstances. However,
most Clojure functions
On Jun 13, 9:24 pm, James Reeves wrote:
> On Jun 13, 4:18 am, Wrexsoul wrote:
>
> > Between files-and-dirs and file-lines-seq I think I have saved as many
> > lines of code as are in the macro+helper fns, so those are at break-
> > even.
>
> I'm not complete
On Jun 13, 4:18 am, Wrexsoul wrote:
> Between files-and-dirs and file-lines-seq I think I have saved as many
> lines of code as are in the macro+helper fns, so those are at break-
> even.
I'm not completely sure what benefit super-lazy-seq is meant to have.
Could you perhaps g
t 'reset! nm gs)) names arglist-1)
~(if skip? :skip [(first arglist)]))))
(defmacro super-lazy-seq [bindings & body]
(let [binds (bindings-to-atoms bindings)
code (with-derefs (set (take-nth 2 bindings)) body)]
`(let ~binds
(letfn [~(make-atom-setter-fn-expr (ta
Well, I did it. Made implementing lazy seqs that require stateful
generator functions easy, that is:
(defn files-and-dirs-recursive [dir]
(super-lazy-seq [stack [(to-file dir)]]
(if-not (empty? stack)
(let [file (first stack) s (rest stack)]
(next-item
file
14 matches
Mail list logo
