AndrevanTonder wrote:
> The fact that, in the proposed modification, the last call to f is not a
> tail call, will adversely affect the space behavious of useful
> programs. Here is a natural example:
>
> (define (print-list list)
> (for-each (lambda (node)
> (if (not (pair? node))
> (display node)
> (print-list (car node))))
> list)
>
> It is easy to exhibit an s-expression for which the r6rs semantics will
> have constant space behaviour, whereas the proposed modification would
> need space
> proportional to the size of the s-expression to run.
I'm having problems seeing the purpose of the function, and also
which lists would be affected by tail-call semantics. (I'm not
not very good with complex recursion, and this is effectively
two nested cursive functions.) Could you explain?
> I would therefore vote for the current tail-recurive specification.
I won't say that the tail-recursive specification is never useful.
However, I think in terms of general performance it is better to
remove the requirement, because it makes generating good code for
for-each much harder. (See my original posting.) People who write
the kind of tricky code where a tail-recursive for-each would be
helpful are capable of writing the needed recursion by hand. (It's
not as if for-each is a very complicated function.) On the other
hand, requiring tail-recursion hurts performance in the normal case,
if you use a compiling that can do inlining without global analysis.
--
--Per Bothner
per_at_bothner.com http://per.bothner.com/
Received on Fri Oct 06 2006 - 17:53:24 UTC