Re: Question about compilation/evaluation environments

From: Duane Rettig (duane_at_franz.com)
Date: 10/03/04 

Date: 02 Oct 2004 17:43:56 -0700

Peter Seibel <peter@javamonkey.com> writes:

> Duane Rettig <duane@franz.com> writes:
>
> >> - BAZ is (minimally) compiled in the compilation environment and
> >> that compiled function is stored as the definition in the
> >> compilation environment for later use.
> >
> > This can't be done if the compilation and evaluation environments
> > are distinct, because the evaluation _must_ be done in the
> > evaluation environment.
>
> What evaluation?

This one from 3.2.1 (emphasis mine):

  The evaluation environment is a run-time environment in
  which macro expanders and code specified by eval-when to be
========^^^^^^^^^^^^^^^
  evaluated are evaluated. All evaluations initiated by the compiler
============^^^^^^^^^^^^^==================^^^^^^^^^^^^^^^^^^^^^^^^^
 take place in the evaluation environment.

When the compiler compiles a form, it calls macroexpand directly with
the compilation environment. When the compiler has to perform evaluation
itself, it must use the evaluation environment. Another way to look at
it: back to the original definition and, for the purpose of discussion:

(defmacro baz (form) `(foo (progn ,form)))

(defmacro baz (form) (foo `(progn ,form)))

In the first definition, which is the way most people are used to seeing
macros, the body of the macro is "data", and it is processed wholely by
the compiler and is macroexpanded in the compiler environment. The second
form (which, though not as common, is stll seen quite often in various
forms) has two components; a data component, and what I'll call a preprocessing
component. Another of the same kind of macro might be something like

(defmacro decide (&whole whole x y)
  (if (symbolp x)
      `(do-it-faster ,x ,y)
    `,whole))

Note that this macro also has a data component (made up of two possible
result forms) and a preprocessing component, which decides which form to
use for the final compilation or evaluation. The (if (symbolp x) ... part
is being run in at macroexpand time, and if it is the compiler encountering
the macro then that preprocessing part is run in the evaluation environment.

> The only evaluation that I see that needs to be done
> to *compile* BAZ is evaluating FOO's expansion function after it is
> found in the compilation environment.

No, in your version of baz (the second one, above) the call to foo is
part of the preprocessing part of the macro, and so is expanded at
macroexpand time in an evaluation initiated by the compiler.
But also, as code to be eventually loaded into a lisp from a fasl file,
the whole form is also processed by the compiler and is macroexpanded
in the compilation environment for the purposes of storing into that
fasl file. Note that the former (the evaluation) is initiated not by the
compilation of baz, but by the use of baz in a compile-time macroexpansion
of quux, which also references baz as part of this "preprocessing" part
of the macro.

 That is, if FOO's expansion
> function uses other functions they must be available in the evaluation
> environment.

FOO was not necessarily found when the macroexpansion for evaluation
occurred. The spec expressly prohibits this assumption. See again:
3.2.3.1.1

> Because in my example FOO contain only calls to PROGN and
> PRINT, both of which are available in the evaluation environment, this
> should work fine. I understand that this may not be the way Allegro
> does it but why is this a non-conforming implementation strategy.

Because you're assuming something that the spec expressly prohibits you
from assuming. What FOO references is irrelevant, if FOO itself is
not found.

I think that you've got yourself stuck into the mode of thinking that
there is only one macroexpansion of baz involved here. Well, there
may in fact be only one call to macroexpand, but it is conceptually
two macroexpansions, and they may have to be separate. I think once
you understand this, everything else will fall into place. 

-- 
Duane Rettig    duane@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182

Relevant Pages

  • Re: Atomic operations in 32 and 64 bit platforms
    ... a compiler to evaluate functions with fixed parameters in any order ... evaluation can involve loading values from memory, ... appear on the x86 stack, that is not defined by the C ...
    (comp.lang.asm.x86)
  • Re: Benefit of not defining the order of execution
    ... Even with a strict order of evaluation, the Rationale's "as if" rule would ... still give the compiler such provisions for optimization. ...
    (comp.lang.c)
  • Re: A C showstopper
    ... measured against the tradeoffs the language is ... order of evaluation was, and might think that the accidental ... choices of one's local compiler were definitive. ... greedy corporations, since it's easier to change the big corporation ...
    (comp.lang.c)
  • Re: Is a[i] = i++ correct?
    ... What the loose order of evaluation buys you is the ability to optimize ... The compiler still can change the order of actual ... undefinedness of the behavior if p and q are aliased, ... Loose evaluation order is merely an optimization crutch which was ...
    (comp.lang.c)