The revised implementation of SRFI-40 uses the delay and force of SRFI-45. <div>On 8/4/07, Will M Farr <<a href="mailto:farr@mit.edu">farr@mit.edu</a>> wrote: <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On Aug 4, 2007, at 5:33 PM, David Einstein wrote: > I was the one who said that srfi-40 streams are tricky.  The fact that > they do not always delay when you expect them to coupled with the fact > that mzscheme 370 will occasionally crash on windows when you run out > of memory (even with memory limited) has caused me a certain amount of > anguish.  It took me a while to get an intuitive sense of what was > going on, but now it pretty much makes sense.  I suspect that either > too many forces, or too few delays are the penalty one pays for lazy > programming in an eager language (the Wadler paper is on my to read > list.) As an aside, you might have a look at SRFI-45 (http:// <a href="http://srfi.schemers.org/srfi-45/srfi-45.html">srfi.schemers.org/srfi-45/srfi-45.html </a> ); it introduces a new primitive, (lazy ...), which acts like an atomic (delay (force ...)) from SRFI-40, but does so "tail-recursively".  This means that many lazy algorithms which should be iterative, but are not with the (delay (force ...)) of SRFI-40, truly become iterative.  (See the srfi document for an extensive discussion of the problems with (delay (force ...)) and unbounded allocation with algorithms that should be iterative.)  Perhaps some of your problems running out of memory could be avoided this way? Will _________________________________________________ For list-related administrative tasks: <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme">http://list.cs.brown.edu/mailman/listinfo/plt-scheme </a> </blockquote></div>