This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
spacey@inch.com writes: > Reading SICP, stream primitives are used to do this sort of of "iterator" > thing, right? These primitives don't seem to be in guile by default. You can define them all in terms of `force' and `delay' if you have a suitable macro facility. Using guile's low-level defmacro: (defmacro stream-cons (a d) `(cons a (delay d))) (define stream-car car) (define (stream-cdr x) (force (cdr x))) And you're all set. > Using a procedure that returns a stream seems to satisfy the > "iterator" qualifications, and the "fetch the whole ball of wax" > qualifications. I guess streams can be thought of as like iterators in some ways. And they can be nicely processed with higher-level oprations - you can't really reverse a stream (since it might be infinite and anyway you'd have to force the whole thing to do it), but you can map and filter it while preserving its useful properties. However, I am not sure a stream would be a useful way to iterate over all the keys in, say, a large database, without using up a lot of memory - you'd have to force each element of the stream to get to the next, and in most ways of using this that I can think of, something somewhere on the stack will be holding a reference to the head of the stream, so it cannot get GCd until the operation completes. > It leaves more work up to the implementor, but it seems that this is what > streams are for... or am I incorrect? > Streams are cool for a lot of things, but are probably likely enough to confuse many people that they shouldn't be the sole interface to key functionality. Obviously someone needs to code a Guile module and/or an SRFI for streams. I might give it a shot, streams are fun. - Maciej