Top-level forms and eval-when in the compiler [and macrolet

["Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>]

    Date: Wednesday, 11 September 1985  20:55-EDT
    From: Masinter.pa at Xerox.ARPA
    To:   Fahlman
    Re:   Top-level forms and eval-when in the compiler [and macrolet
          too!]

    Your answer isn't acceptable. No Common Lisp is "serious" unless it has
    a compiler, and there are many things in Guy's book that are meaningless
    unless there's a compiler (compile-file, declarations, defconst,
    optimize, etc.)

    While it might have been politic at the time the book was being put
    together to say "Common Lisp compilers are not required to do any work
    at all, or even to exist for a given implementation", all of the real
    ones *do*, and if most implementations have a feature, then the feature
    should be standardized. 

In answering these queries, I try to keep three things separate: what is
required by the current language definition, as I understand it; what I
think that every reasonable implementation ought to do; and what I think
ought to be added to the language specification in the future.  So what
I was saying is that, according to the current definition of Common
Lisp, I think that it is legal either to compile or not to compile a
Defun within a Macrolet; I also said that I thought an implementation
ought to compile such forms.  Do you disagree with either of those
statements?

Presumably what you found unacceptable was that the language
specification allowed something like this (and almost everything else
about what the compiler does) to be unspecified.  I can't subscribe to
your sweeping statement that "if most implementaitons have a feature,
then the feature should be standardized".  Our strategy has been to
standardize all those things which must be standardized in order to
allow code to be portable.  Things which do not impact the portability
of code have in general been left unspecified.  In particular, we have
tried not to specify too much about the internals of an implementation
so that Common Lisp can be implemented on a wide variety of machines
using a wide variety of implementation techniques.  Similarly, we have
not specified more than is absolutely necessary about the user
interface, so that implementors have some freedom in adapting Common
Lisp to thier own system's local culture.  We had in mind, for example,
Interlisp people who might want to stick with an internal editor instead
of being required to live with an EMACS front end.

It is of course a tricky balancing act to decide just how much to nail
down.  For example, I think that we would all agree that the language
spec ought not to specify exactly which things are to be open-coded by
the compiler and which left as function calls; to do so would be to put
some class of machines at a severe disadvantage.  On the other hand,
writers of code intended to be portable will tend to write code whose
performance is optimized according to some assumptions about how most
Common Lisps are organized.  For example, they will tend to assume that
it is OK to use macros freely because these are expanded out at compile
time and are probably cached by the interpreter.

If we can make such implementation techniques more uniform without
really screwing any reasonable implementation, then we should probably
do so; it will make it possible to port more code to more machines
without extensive retuning.  This could be done by REQUIRING certain
implementation techniques to be followed, or it could be done by
"implementation notes" in the manual suggesting that things be done in
certain ways if at all possible.  In the past we have favored the
latter, perhaps because there was so little implementation experience to
draw upon that we didn't want to absolutely rule out any alternatives.

I suppose it would be reasonable to require that Defuns embedded in
random top-level forms get compiled just like top-level Defuns do
(whatever that may entail in a given implementation).  At least, future
editions of the manual should make some strong suggestions along these
lines.

-- Scott