On Tue, Oct 22, 2002 at 02:34:19PM +0200, Gerd Moellmann wrote:
>
> Adam Warner <[EMAIL PROTECTED]> writes:
>
> > In: defun-grab plus1
> > (defun-grab plus1 (number) (1+ number))
> > --> progn eval-when defparameter progn
> > ==>
> > (setq plus1 '(defun plus1 (number) (1+ number)))
> > Warning: Undefined variable: plus1
>
> I think this from CLHS might be relevant:
>
> defparameter and defvar normally appear as a top level form, but it is
> meaningful for them to appear as non-top-level forms. However, the
> compile-time side effects described below only take place when they
> appear as top level forms.
>
> [...]
>
> Side Effects:
>
> If a defvar or defparameter form appears as a top level form, the
> compiler must recognize that the name has been proclaimed
> special. However, it must neither evaluate the initial-value form nor
> assign the dynamic variable named name at compile time.
>
> There may be additional (implementation-defined) compile-time or
> run-time side effects, as long as such effects do not interfere with
> the correct operation of conforming programs.
I was motivated to rip so much stuff apart in pursuit of correct
EVAL-WHEN behavior ca. sbcl-0.7.0 not because I do a lot of exotic
things with EVAL-WHEN in application code, but because so many of the
magic-at-toplevel operators like DEFUN, DEFSTRUCT, and DEFVAR are
naturally defined in terms of EVAL-WHEN. Then when EVAL-WHEN behaves
correctly, all sorts of special cases, e.g. Adam's and also
(defun foo (x)
(if x
(defstruct foo a)
(defstruct foo b c)))
(compile *)
start to work as ANSI specifies.
--
William Harold Newman <[EMAIL PROTECTED]>
rather lucky so far
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
