[Openmcl-devel] DEFCONSTANT and runtime environment

[Gary Byers]

On Mon, 28 Jan 2002, Eric Marsden wrote:

> Hi,
>
> OpenMCL behaves rather differently from other implementations in the
> way that COMPILE-FILE adds information to the evaluation environment.
> Consider code like
>
>    (defconstant +foo+ #\a)
>    (defun foo () #.(char-code +foo+))
>
> This doesn't compile on OpenMCL. CLHS 3.2.3.1.1 "Processing of
> Defining Macros" says that DEFCONSTANT must "make definitions
> available both in the compilation and run-time environments". So I
> take it the evaluation and runtime environements are separate.
>
> What idioms do people use to get around this? Wrapping everything with
> EVAL-WHEN?

Yes (though personally I don't think think of it as "getting around"
anything; that may be a minority opinion.)

To try to explain some of why OpenMCL/MCL behaves the way it does:

OpenMCL (like MCL) tries to minimize the compile-time effects of
defining forms on what CLHS calls "the evaluation environment".  (It's
not always successful in this: DEFTYPE and DEFSETF and possibly a few
other things are put into effect globally at compile time; DEFCONSTANT
and DEFMACRO and - assuming that certain functions aren't missing -
DEFINE-SYMBOL-MACRO make the definition available in the lexical
environment but don't affect the (possibly incompatible) "evaluation
environment".)

The rationale for doing it this way is twofold:

  a) it allows one to compile code containing new/incompatible
  definitions of constants/macros/etc. without side-effecting (and
  possibly breaking) the lisp ("the evaluation environment" may
  intersect with critical parts of the implementation or with user
  code.)  This can greatly simplify bootstrapping and
  cross-compilation.

  b) One can always request (by surrounding the defining form in an
  (EVAL-WHEN (:COMPILE-TOPLEVEL ...) ...) ) that the defining form
  should have globally-visible effects.  If this were the default
  behavior, it's not clear what one would say if one wanted/needed to
  limit those effects.

CLHS leaves many aspects of the behavior of defining forms
unspecified: DEFCONSTANT, for instance, might evaluate the "value"
form at compile-time, load-time, or both. The issue of whether or not
compile-time evaluation affects the "evaluation environment" or just
the lexical environment is only relevant if compile-time evaluation
takes place.

The X3J13 cleanup issue on which much of section 3.2.3.1.1 of the CLHS
is based ("COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS:CLARIFY") is, to me,
a little clearer than that section of the CLHS is.  I find it interesting
to note that one of the principle motivations for that cleanup issue was
considerable variance in existing implementations' handling of DEFCONSTANT,
and difficulty in reaching consensus on what was the "right" behavior;
I'd be surprised (not shocked, but surprised) if all current implementations
besides [Open]MCL behave identically to each other.

The quality of being intuitive - intuitiveness ? - tends to be in the eye
of the beholder.  If behavior that I find useful and intuitive is obscure to
and unexpected by most users, then it's probably not a good default. I
suspect that it's possible to control how defining macros behave via an
argument to COMPILE-FILE or some similar mechanism.

> --
> Eric Marsden                          <URL:http://www.laas.fr/~emarsden/>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel