Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)

[David N Gray <Gray@DSG.csc.ti.com>]

> Issue:        TAIL-RECURSION-OPTIMIZATION
> References:   5.1 Forms (pp54-59), SYMBOL-FUNCTION (p90)
> Category:     CHANGE
> Edit history: 31-Aug-88, Version 1 by Pitman
> Status:	      For Internal Discussion
> 
> Problem Description:
> 
>   Useful tail-recursion optimizations are not permitted by CLtL because
>   the compiler must assume that any opaque function call might change
>   the definition of a function in between calls to that function, so a
>   direct jump to the code is not appropriate.

"Tail-recursion optimizations" could mean one of two things:  either
a function that calls itself being optimized into a loop, or jumping to
another function while keeping the same stack frame.  Your examples only
mention the first case; I don't see that the second is any problem.  I'm
not even convinced that the first case is really a problem since I haven't
seen an example of meaningful code where it would not be safe to assume
that a function didn't redefine itself (other than the DEFUN-AUTOLOADING
example, which is not a likely candidate for optimization anyway).  In any
case, all one would have to do to insure a run-time indirection is to do 
(FUNCALL (SYMBOL-FUNCTION 'FOO) ...) instead of (FOO ...).

Anyway, I think it would be a mistake to tie this issue with the
SPEED and NOTINLINE declarations since they are intended to affect
efficiency, not the semantics of the code.

> Current Practice:
> 
>   Symbolics Genera and Symbolics Cloe not currently do tail recursion
>   optimization. As such, they are compatible with the proposal.

The TI Explorer does do tail recursion optimization (both kinds) at higher
optimization levels.  It does assume that a function won't redefine
itself, but no one has reported that as being a problem.

  -- David Gray