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

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

> Just inferred. Why?

I just wanted to see something a little more specific than "CLtL says".

>     > Proposal (TAIL-RECURSION-OPTIMIZATION:PERMIT-EARLY-BINDING):
>     > 
>     >   Permit early binding in some situations, but do not require them.
> 
>     This doesn't define what "early binding" means.  The test cases suggest
>     what the intent is, but I'm not comfortable with specification by
>     example.
> 
> Can you suggest a wording?

I'm still not clear on what you intended, but here's a minimal
specification that I could support:

Within the body of a DEFUN, if the CAR of a function call form is the
same as the name of the DEFUN, and that name has not been locally
shadowed by an FLET or MACROLET within the DEFUN, then a compiler is
free to assume that the reference is to the current function object
without requiring a run-time lookup of the symbol's function
definition.

You might want to extend this to a self-reference in a FUNCTION form,
but that is less interesting for optimization and causes the auto-load
example to be a problem.

>     In particular, it isn't clear whether you intend to affect the
>     case of one function calling another, or if you are only talking about
>     functions that reference their own definition.
> 
> I see no reason to distinguish. Do you agree? If not, can you please make
> a case for why a function referencing itself should be different than a 
> function referencing another function.

No, I don't agree.  In the case of a function that references itself,
there can only be an inconsistency if the function is redefined during
execution of the function, which is not very likely.  However, when
calling another function, one would have to presume the possibility that
the other function will be changed before the current function is
changed.

>   This is the kind of thing I worry
> about:
>  (SETQ FACT '(LAMBDA (X) (COND ((ZEROP X) 1) (T (* X (FACT (- X 1)))))))
>     (COMPILE 'FACT FACT)
>  vs (SETF (SYMBOL-FUNCTION 'FACT) (COMPILE NIL FACT)).
> Any difference in behavior/efficiency of these two forms would seem
> highly gratuitous to me.

But how can any optimization be done in the second case, where the call
to FACT is referencing a function that isn't defined at the time of
compilation?