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

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

Item 2c (block compilation) has been more controversial -- KCL does
this, but many people seem to think that this should not be the
default behavior of the compiler.  My plan for voting on this issue at
the last meeting was to first ask for a vote on an amendment to remove
this particular item, but it never got that far.  I suppose that if
nobody speaks up for it in the meantime, we could just go ahead and
remove it from the next version. 

> The second proposal paragraph says: [...]
> 
> What precisely is a "transformation"?  I think this paragraph
> doesn't mean anything and should be removed.

We have another issue, COMPILED-FUNCTION-REQUIREMENTS, that deals with
this in more detail, so removing the paragraph here would be OK with
me. 

-Sandra
-------