Re: issue WITH-COMPILATION-UNIT, version 3

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

> Date: Tue, 14 Mar 89 13:03 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> I don't think it's acceptable to have something like this if its effect
> is only defined for warnings, and its effect on compile-time
> proclamations, compile-time macro definitions, compile-time defconstant
> definitions, compile-time optimizer definitions, compile-time type
> definitions, compile-time setf definitions, and compile-time CLOS
> definitions is left unspecified.

This point has been raised before.  Some of us have suggested that the
purpose of WITH-COMPILATION-UNIT is really to allow several files to
be treated as a unit sharing a single compilation environment, which
would include the information about undefined functions as well as all
the things you list above.  However, the whole notion of compilation
environments is still pretty vague right now and I don't really blame
Kent for wanting to avoid the issue.  I guess the real questions are,
can we firm up something on compilation environments in time to make
it into the standard; and if not, should we delay adding this feature
or define only the restricted form that Kent proposes? 

> I think lumping COMPILE and COMPILE-FILE together here reflects
> confusion.  COMPILE and COMPILE-FILE have very little to do with each
> other, and I think it's clear that COMPILE should not be affected in any
> way by WITH-COMPILATION-UNIT.

I agree with this.  In particular, the extended notion of what this
form is for is sharing of what we have been calling a "remote"
environment across multiple calls to COMPILE-FILE.  COMPILE always
uses a "local" environment and shouldn't be affected.

-Sandra
-------