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

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Mon, 3 Oct 88  19:10:11 CDT
    From: David N Gray <Gray@DSG.csc.ti.com>

    >   Early binding of function names to function definitions is generally
    >   inhibited in Common Lisp because CLtL says the compiler must assume
    >   that any opaque function call might change the definition of a
    >   function in between calls to that function.

    Is there a specific place in CLtL that clearly says that, or is it
    just inferred from the ability to SETF SYMBOL-FUNCTION without
    restrictions on where or when?

Just inferred. Why?


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

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

    >   Specifically, with SPEED=0, the compiler should not do early binding
    >   (for the sake of tracing, stack debugging, and reloading in
    >   interactive debugging), ...

    Given that intent, if proposal OPTIMIZE-DEBUG-INFO:NEW-QUALITY is
    adopted, then a more appropriate criteria might be DEBUG>SPEED.
    Actually, though, if debugability is the issue, this might be beyond
    what the standard ought to specify, since nowhere else does it specify
    what happens at particular optimization levels.

If the new quality passes, I think we should haggle about this. I write
my proposals based on what's true at the time they will be voted on.
Right now, there's little guidance about the qualities, and DEBUG is
not one. The note in the Discussion about this is intended to handwave
this issue. I could expand the note or move it to the proposal section
if you thought it really important.

    >     ... but with in other with higher speed settings, ...

    The grammar didn't come out right on that.

Right.

    >   regardless of the OPTMIZE SPEED setting.

    OPTIMIZE

Right.

    >   of the OPTMIZE SPEED setting.

    ditto

Hmmm. I detect a pattern.

    > Current Practice:
    > 
    >   Symbolics Genera and Symbolics Cloe not currently do early binding.

    "not" -> "do not"

Right.

    >   David Gray has expressed reservations about this to the OPTIMIZE SPEED
    >   quality at all since he sees it as a semantic issue.

    ... about tying this to the OPTIMIZE qualities ...
    Actually, I thought _you_ were presenting it as a semantic issue.

Only in the sense that the current description forces it to be. By
saying that SYMBOL-FUNCTION holds the function that will be called, CLtL
really tied our hands. This proposal is trying to get away from that and
make it an efficiency/debugging issue rather than a semantic issue.
Does that make sense?

Thanks for your careful reading and criticism.