Questions and an offer concerning "EVAL-WHEN" issues.

["BACH::GREEK" <greek%bach.decnet@hudson.dec.com>]

Here is some food for thought concerning the "EVAL-WHEN" issues.


Let's assume that we define the "global environment" as that
information established by the read-eval-print loop or loaded from
files.

And let's define the "compilation environment" as the information
established by compilations.

How about these for three rules (certainly open to debate).

  1.  The compiler is required to use information in the global
      environment.

  2.  The compiler is required to use information in the compilation
      environment established by prior compilations.

  3.  The compiler is not allowed to affect the global environment.

Many schemes can be devised to implement these rules, but no matter how
clever they get, it's tough to solve the following problems.

  o  How does the user alter the readtable for the duration of a 
     compilation but not permanently?

  o  How does the compiler handle package functions in the source file
     without actually evaluating them?

  o  What about necessary uses of (EVAL-WHEN (COMPILE) ...), such as
     DEFCONSTANTs used as keys with the CASE macro?

  o  Etc., etc.

Thinking about schemes to implement these rules also brings up
questions of the organization of source files.  For example, is it OK
for a file to contain contradictory proclamations:

  (PROCLAIM '(FIXNUM *FOO*))
   .
   .
  (PROCLAIM '(SIMPLE-STRING *FOO*))

In other words, is a proclamation static or "scoped"?  Without getting
too clever, you can write a source file which knows whether the
compiler is one-pass or multi-pass.

How about the question of which "top-level" forms the compiler pays
special attention to.  For example, we know that the compiler notices
a DEFMACRO so that it can expand such macros later on.  What makes it
notice the macro?

  1.  The presence of the LOAD situation (which is the default).

  2.  The presence of a hidden situation, say called COMPILER-NOTICE
      (this must also be the default).

  3.  Nothing in particular, it always looks at it.

If you think a bit, you'll find problem with all three of these
theories.  In particular, how do you tell the compiler to notice the
macro definition but not dump it?  What else does the compiler pay
special attention to?  How about DEFUN?  Can I call a function from
a macro expander and expect that to work?  How do PROVIDE and REQUIRE
work during a compilation?

Then there is the age-old question of whether an unqualified symbol
should be loaded into the package that was current at compilation time
or the package that is current at load time.  If the latter, how do you
distinguish an unqualified symbol from one that was explicity qualified
with the package current at compilation time?

Should there be a function to flush the compilation environment?  One
might use this in between compilation of two sets of related files.
This causes one to wonder if the compilation environment shouldn't be
trashed after every compilation, forcing users to compile related files
using PROVIDE and REQUIRE (see above).


If people are interested in compiling a list of compilation environment
questions, so that we have a place to start in solving these problems,
I'd be happy to collect the questions and compile a complete list.

- Paul
------