Date: Thu, 28 Jun 2012 17:59:39 -0400
   From: John Cowan <cowan@mercury.ccil.org>
   Cc: alexshinn@gmail.com, scheme-reports@scheme-reports.org

   Richard Kelsey scripsit:

   > 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.

   The report as a whole talks about proper tail recursion, not about
   safety for space, and it has always been the case that implementations
   like Chicken, which are only asymptotically safe for space, have been
   considered properly tail recursive.  I'd prefer to talk of proper tail
   recursion here also, so I reject this language.

Proper tail recursion is not the issue here, so it doesn't help
much to talk about it.  I was trying to mimic the description of
proper tail recursion:

  A Scheme implementation is properly tail-recursive if it supports an
  unbounded number of active tail calls.

I don't think using the exact language works, because delay-force
isn't 'active' in the same way.
                                      -Richard Kelsey

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