[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some suggestions

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:

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.

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