[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: COMPILE-ENVIRONMENT-CONSISTENCY (Version 3)
- To: Sandra J Loosemore <firstname.lastname@example.org>
- Subject: Re: Issue: COMPILE-ENVIRONMENT-CONSISTENCY (Version 3)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 27 Jan 89 21:10 EST
- Cc: CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
- In-reply-to: <8901251616.AA20436@defun.utah.edu>
Date: Wed, 25 Jan 89 09:16:50 MST
From: email@example.com (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.