Thanks!  This had already been fixed in the repository and
   currently reads:

     The expression (delay-force expression) is conceptually similar to
     (delay (force expression)), with the difference that forcing the
     result of delay-force will in effect result in a tail call to (force
     expression), while forcing the result of (delay (force expression))
     may not.  Thus iterative lazy algorithms that may result in a long
     series of chains of delay and force can be rewritten using
     delay-force to prevent consuming unbounded space during evaluation.

   (where lazy has been renamed delay-force).

This seems overly coy.  What matters is heap space, not whether the
call to 'force' is a tail call.  How about something like:

 (delay-force expression) is identical to (delay (force expression)),
 with the additional requirement that implementations must support
 tail-recurive nesting of delay-force (where expression returns the
 result of a second use of delay-force) to arbitrary depths.  This
 allows delay-force to be used to write lazy, iterative loops as in
 the stream-filter example below.  See section 7.3 for an example of
 how delay-force can be implemented.

                                          -Richard Kelsey

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports