Re: Defun inside Let

[Steven Haflich <smh@mit-ems.ARPA>]

> From @SU-AI.ARPA:REM@IMSSS Thu Jan 30 19:00:10 1986
> 
> But if you had explicitly recovered the lexical environment from
> either add-and-increment or sub-and-decrement (either will do in this
> case), and executed the new DEFUN in that environment, then the new
> function-object could share lexical a,b once again.

> I'm under the impression lexical environments (except possibly the null
> environment) can't get new variables once they are formed, but there
> were suggestions to change this both for debugging reasons and for
> consistency with the null environment.

I'm under the same impression.  There is a very good motivation for
hiding the insides of lexical closures:  The compiler (and by
implication also the interpreter) is allowed to do whatever flow and
variable analysis it can in order to bum or completely eliminate
closures.  By requiring that it be possible subsequently to modify a
closure, such analysis becomes impossible.  See the four examples on
CLtL pp.88-9 where in one case the compiler can avoid making a closure,
and in another merge many closures into a single object.

These optimizations could be especially important when compiling
automatically-generated code.  It is worth every bit of effort to make
CL compilers super-analyzing/optimizing, because that's the place in a
CL system that has the most leverage on language performance.
   
> Has anybody written a completely correct implemention of CL so that we
> can establish by example that CLtL isn't self-contradictory??

How would he know if he had?  If knowing were so easy, compiler
validation wouldn't be the subject of so much research.  And we
wouldn't hear about validation suites in Ada land that execute
such-and-so percentage of the language features...