Re: Issue: COMPILE-ENVIRONMENT-CONSISTENCY (Version 3)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Wed, 25 Jan 89 09:16:50 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Tue, 24 Jan 89 21:10 EST
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    > This is said to be a clarification, but I believe it is a change because
    > it makes the default semantics very different from the NOTINLINE
    > semantics (items 2b and 2c).  However, I can't find anything in CLtL
    > that's contradicted by this proposal.

    I suppose the most consistent specification would be to only allow
    tail recursion optimization in the -presence- of an INLINE
    declaration.  But I think the current wording of item 2b more closely
    represents current practice.  It's how A-Lisp and Utah Common Lisp
    work, and I think VaxLisp does this also.  The rather ancient version
    of Lucid Lisp I have seems to do tail recursion optimization even if
    you proclaim the function NOTINLINE.  Is there some other particular
    behavior you'd like to see specified instead? 

Not really.  On the whole I would prefer that user-defined functions are
NOTINLINE by default, and only an INLINE declaration allows the compiler
to assume that the function<->function-name association will not change.
However, I'm not strongly opposed to your idea of introducing a third
state in addition to INLINE and NOTINLINE, and making it the default.

    Item 2c (block compilation) has been more controversial

I cannot think of any believable justification for favoring tail
recursion in the absence of an INLINE declaration yet opposing block
compilation in the absence of an INLINE declaration.  I think we should
either allow neither or allow both.