This page is part of the web mail archives of SRFI 40 from before July 7th, 2015. The new archives for SRFI 40 contain all messages, not just those from before July 7th, 2015.
>>>>> "Matze" == Matthias Neubauer <neubauer@xxxxxxxxxxxxxxxxxxxxxxxxxx> writes: [snip] Matze> Another example is the definition of STREAM-FILTER. Suppose you have a Matze> non-leaking implementation of STREAM-DROP-UNTIL at hand [1], the Matze> following simple definition of STREAM-FILTER should (hopfully) also Matze> make sense: Matze> (define (stream-filter pred? stream) Matze> (stream-unfold (lambda (stream) Matze> (let ((stream-1 (stream-drop-until pred? stream))) Matze> (cons (stream-car stream-1) Matze> (stream-cdr stream-1)))) Matze> stream)) Matze> Here the "state" that is passed from step to step is the remainder of Matze> the original stream that still has to be processed for the next Matze> element. The actual processing in each step is then performed by Matze> calling STREAM-DROP-UNTIL. [snip] Matze> [1] Which isn't the case with the current reference implementation I Matze> just realized. Your STREAM-DROP-UNTIL bares the same space problems as Matze> the naive STREAM-FILTER implementation does. Your code above leaks space even if STREAM-DROP-UNTIL doesn't: the closure handed out to STREAM-UNFOLD holds a reference to STREAM. This isn't just a nitpick: I think it shows that using STREAM-UNFOLD doesn't gain you as much simplicity as you might would expect. This doesn't add anything to the STREAM-UNFOLD vs. STREAM-ITERATE debate of course. -- Martin