[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: firstname.lastname@example.org
- Subject: Issue: PROCLAIM-ETC-IN-COMPILE-FILE
- From: vanroggen%aitg.DEC@decwrl.dec.com
- Date: Wed, 21 Sep 88 08:09:45 PDT
If DEFPACKAGE is adopted, would we want to remove the package related
functions from this list of specially treated top-level forms?
I think if we want to allow implementations the freedom of whether PROCLAIM
affects either the compilation environment or the compiler's run-time
environment, we should allow implementations to affect both as well.
I really don't think PROCLAIM '(OPTIMIZE ...) should be a special case.
It's much simpler to think of PROCLAIM always affecting global information.
Also, how would one cause the PROCLAIM '(OPTIMIZE ...) to be evaluated
at load time? Is it assumed to be wrapped in an EVAL-WHEN (COMPILE EVAL)
if the argument is (QUOTE (OPTIMIZE ...)) but in an EVAL-WHEN (COMPILE LOAD
EVAL) otherwise? What if the argument isn't quite of that format? And
how would a user get the behavior, if the default behavior is to just
affect the compilation environment, to get both that and have it be
executed at load-time?
BTW, for the current practice section, we do evaluate the argument to
PROCLAIM, but we don't call the normal PROCLAIM--instead we record
information differently than would happen with (EVAL-WHEN (COMPILE)