Issue ALLOW-LOCAL-INLINE (V2)

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

In accordance with Pitman's suggestion of 9/24, I withdraw proposal
ALLOW-LOCAL-INLINE:PROCLAIM-ALLOW-INLINE and offer the following in
its place.


Issue:		ALLOW-LOCAL-INLINE
References:	CLtL p. 156, 159;
		Issue PROCLAIM-INLINE-WHERE
Category:	CLARIFICATION
Edit History:   21 Sept. 88 V1 by David Gray
                27 Oct.  88 V2 by David Gray - new proposal
Status:		For preliminary discussion 
 
Problem Description:

  The proposal PROCLAIM-INLINE-WHERE:BEFORE (which was accepted by X3J13
  on 10/12/88) clarifies the use of INLINE proclamations, but there
  remains a similar problem with the use of a local (DECLARE (INLINE
  ...)): how can the compiler expand the function inline if it didn't
  know that the necessary information should have been saved when the
  function was compiled?
 
Proposal ALLOW-LOCAL-INLINE:INLINE-NOTINLINE

  Clarify that if a local (DECLARE (INLINE foo)) is to be used to expand
  a function inline in only certain places, then the function should be
  defined like this:
    
   (PROCLAIM '(INLINE foo))
   (DEFUN foo ...)
   (PROCLAIM '(NOTINLINE foo))

  The INLINE proclamation preceding the DEFUN ensures that compiler will
  save the information necessary for inline expansion, and the NOTINLINE
  proclamation following the DEFUN prevents it from being expanded
  inline everywhere.  

  Note that while implementations are never required to perform inline
  expansion of function calls, many implementations that do support
  inline expansion will not be able to respond to local INLINE requests
  if this technique is not followed.

 Rationale:

  Local INLINE declarations are of little use without some way of
  alerting the compiler to the possibility of inline expansion before
  the function is compiled.  This seems the simplest solution since it
  just clarifies existing practice instead of adding a new feature to
  the language.

  A compiler could use some heuristic to save the definitions of functions
  that are short enough to look like good candidates for inline expansion,
  but then the user is never sure what to expect.  It is possible that a
  compiler could simply save all definitions (assuming availability
  of adequate storage space) but we shouldn't require that.

 Test Cases/Examples: 

  Given the following input to COMPILE-FILE, does F1 get expanded inline
  in F2, and does F3 get expanded inline in F4?

    (defun f1 (a) (+ a 100))
    (defun f2 (b) (declare (inline f1)) (f1 b))
    (proclaim '(inline f3))
    (defun f3 (a) (+ a 100))
    (proclaim '(notinline f3))
    (defun f4 (b) (declare (inline f3)) (f3 b))
 
 Current Practice:
 
  In the example above, using Symbolics, Lucid, or Explorer, F1 is not
  expanded in F2, but F3 is expanded in F4.

 Cost to implementors:
 
  None, since this is a clarification in accordance with current
  practice.

 Cost to users:
  
  None.

 Benefits:

  Users will be able to use (DECLARE (INLINE ...)) with greater assurance
  that it will really do something.

 Costs of Non-Adoption: 

  Users will not know how to reliably request inline expansion on a
  local basis.  This technique is not obvious, and even the need
  for it likely to be apparent only to people who understand something
  about how the compiler does inline expansion.

 Discussion:

  Version 1 of this issue proposed an addition to the language:
    (PROCLAIM '(ALLOW-INLINE foo))
  This was met with a lack of enthusiasm since it was pointed out that
  the same effect could be obtained by using a combination of INLINE and
  NOTINLINE.