Top level forms in a compiled file

[BENSON at SPA-Nimbus]

    Received: from USC-ECL by SU-AI with TCP/SMTP; 14 Jul 83  07:40:42 PDT
    Received: from MIT-MC by USC-ECL; Thu 14 Jul 83 07:39:50-PDT
    Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Thu 14-Jul-83 10:27:37-EDT
    Date: Thursday, 14 July 1983, 10:35-EDT
    From: Bernard S. Greenberg <BSG%SCRC@MIT-MC>
    Subject: function specs
    To: EAK@MIT-MC, common-lisp%SU-AI@USC-ECL
    In-reply-to: The message of 13 Jul 83 23:00-EDT from Earl A. Killian <EAK at MIT-MC>

	Date: 13 July 1983 23:00 EDT
	From: Earl A. Killian <EAK @ MIT-MC>
	Btw, I would consider any compiler that didn't compile the lambda in

	(putprop 'foo #'(lambda (x) (mumble-frotz x)) 'bar)

	to be broken.

    Surely, if the form above appears in the middle of a function.
    But what about forms that appear at the top level?  I don't think there
    is a clear notion of what happens to top level forms that are not 
    macro invocations.  Traditionally, these forms go into the object file
    unmodified (just encoded).  Should constant expressions be reduced? 
    Should diagnostics be issued?  Should internal macro calls be expanded?

    In order for the compiler to compile lambdas in top level forms, a solid
    theory of processing top-level function calls has to be developed, which
    implies a new, fundamental mode of meta-evaluation, viz., compiler-top-level, 
    to be added to the current set of language-defined meta-evaluations
    (true evaluation and compilation).

There is a solution to this problem.  Collect all the top level
forms in the file into a function of no arguments and compile the
function.  When the compiled file is loaded, call the function and throw
it away.  This is the strategy I chose for PSL's compiler and binary
loader.  Thus, anonymous lambdas outside of named function definitions
are compiled by the same means as those which are inside functions.
Other advantages are conceptual simplicity, ease of implementation, and
faster loading.

There are problems with this approach.  The top-level function which
must be compiled is sometimes huge, much larger than any real function.
Compilation is slower.  People tend to be much sloppier in what they
write at the top level than inside functions (because they never
expected it to be compiled!).  Top level forms sometimes modify the
global state such that a monolithic compilation does not have the same
semantics as incremental evaluation.  The most common example of the
latter is package manipulation, which changes the behavior of the
reader.

Whether or not this exact approach is taken, I think it is quite
reasonable to expect top level forms in a file being compiled to be
treated the same as forms within function definitions, including
diagnostics, constant sharing and compilation of lambda forms.

-- Eric