RE: Issue ALLOW-LOCAL-INLINE (V3)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

In the same file only in a very strange sense: I'm worried about interactive
debugging, where I make something inline and then later decide that was a bad
idea. Symbolics Common Lisp has a construct called DEFSUBST which behaves
identically to the DEFUN-INLINE I described. The problem is that CL's INLINE
semantics screws it because if you change a DEFSUBST to a DEFUN in the editor
and re-evaluate that single definition (which is how you do program development
on LispM family computers), you find that even though you've now written DEFUN,
the INLINE info set up by the DEFSUBST persists because there is no way for the
editor to know that you hadn't written
(PROCLAIM '(INLINE FOO))
(DEFUN FOO ...)
and that you weren't just re-evaluating the DEFUN part expecting the INLINE
stuff to persist. If indeed we made the contract of INLINE be that the info
went away on subsequent redefinition, then the editor could know you weren't
just reevaluating the DEFUN hoping the INLINE info would persist by definition:
the INLINE information wouldn't be permitted to persist, and you'd have to 
re-evaluate both the (PROCLAIM '(INLINE ...)) and the DEFUN to get the info to
persist.

-Unfortunately-, as I've just realized in writing this, if you do
 (PROCLAIM '(INLINE FOO))
 (DEFUN FOO ...)
 (PROCLAIM '(NOTINLINE FOO))
 (PROCLAIM '(INLINE FOO))
 (PROCLAIM '(NOTINLINE FOO))
 (PROCLAIM '(INLINE FOO))
and later do a DEFUN, there is still no way for the editor to tell the
difference between the two kinds of INLINE declaration, and so the later
DEFUN would still end up inlined.

This makes me think that Gray was right in suggesting that ALLOW-INLINE
is needed. I'll have to think on this more before sending mail to the whole
list.