Re: Issue ALLOW-LOCAL-INLINE (V2)

[Rob.MacLachlan@WB1.CS.CMU.EDU]

One problem with the inline-notinline idiom is that NOTINLINE has evolved
in the direction of a declaration that tells the compiler "assume nothing
about this function".

NOTINLINE would certainly suppress block-compiled call, and would probably
suppress compiler warnings about the argument signature used in calls, etc.
A programmer who just wants to note the inline expansion and not use it
right away shouldn't be forced to suppress standard compilation on the
calls that aren't inline-expanded.

In fact, I think that there is a reasonable argument that NOTINLINE should
cause the compiler to *forget* any recorded inline expansion.  Assuming
that a previously seen definition is in fact the correct definition seems
to be making a pretty strong assumption about that function.

It is because of of this continuum of levels of "assumption about a
function" that I proposed the INTEGRATION-LEVEL declaration to subsume
INLINE and NOTINLINE.  The idea was that NOTINLINE = 0 and INLINE = 3, and
any value > 0 allowed the compiler to assume that any seen definition is
the true definition, but what use it made of this information was up to it.
For example,
    (proclaim '(integration-level 2 foo))

could cause the expansion to be recorded without causing inline expansion
to be done.

To go along with this, there was the notion of the default integration
level, which was initially 1 and could be modified by a proclamation.

This isn't exactly what I proposed before, and I think that this proposal
might also benfit from modification.  In particular, it isn't clear that it
is really appropriate or useful to use integers to represent the
integration level (although it does make sense to have an ordering on the
values).  An alternative would be to use some small set of keywords such as
:NEVER, :DEFAULT, :RECORD and :INLINE.

  Rob