Top level forms in a compiled file

[Bernard S. Greenberg <BSG%SCRC@MIT-MC>]

    Date: Thursday, 14 July 1983, 11:54-PDT
    From: BENSON at SPA-Nimbus
	Date: Thursday, 14 July 1983, 10:35-EDT
	From: Bernard S. Greenberg <BSG%SCRC@MIT-MC>
	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
    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.
Yes and no.  This causes exactly the right things to happen to the forms
themselves, but...
    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.
The evaluation order here is absolutely critical, and kills your whole thing.
It is completely reasonable and extraordinarily common to call functions 
defined two lines above.  I guess you could say, "Well, run it at the end,
not at the beginning", but there could be load-time forms in your functions.

I had often thought of compiling a little functionelle for each top-level
form.