Re: Local redefs of special forms

[Jeff Barnett <jbarnett@nrtc.northrop.com>]

If you allow FLETS, et al, to shadow special forms, there is an implementation
issue with inline function expansions nee DEFSUBSTs.  The compiler cannot
substitute the function body and optimize as some compilers now do.  In fact
the body must be (re)expanded in the null lexical environment no matter what.
Consider the following example:

(defsubst foo (x) (car x))

(flet((car (l) (cdr l)))
  (foo (car q)))

The value of the flet should be (cadr q) while if the compiler is not careful,
the result will be (cddr q) instead.  Note, this issue has nothing to do with
special forms, it depends only on the interaction between an inline function,
the defsubst, and local function defs, the flet.  In order to get the proper
semantics AND the optimization implied by using an inline function, a compiler
must mark expressions with their lexical environment.  Perhaps the expression
(foo (cdr q)) in the above would need to look something like
     (#<env 1> (foo (car q)))
     (#<env 0) (foo (#<env 1> (car q)))
     (#<env 0> (car (#<env1> (car q))))
and if the flet is inlined
     (#<env 0> (car (cdr (#<env 1> q))))
at different times as the compiler elaborated the original.  Note, the env
wrap around the variable is necesssary also:  Think about the interactions
that might result (with more complex local fcn defs) if there is a special
declaration around an inline expansion
    (let(...)
      (declare ....)
      (in-line-fcn reference ...) ...)
If the subst's body is just substituted AND it binds a declared variable, all
hell will break loose.

I don't think that you can get out of the delemma without some sort of env
wrapper.  In any event, there needs to be a good set of primitives to
manage and interagate environments so that sexy system macros and substs
don't blow the bunnies.  As long as they need to exist, why not standardize,
document, and distribute them?