#95 eval-when and top-forms
These are some ANSI compliance bugs in the
implementation of eval-when (at least in clisp 2.27 and
clisp 2.28):
1) In prompt [63] (below), when compiling the code
(below), clisp prints 2, 3 and 5. 2 being printed is ok
according to:
"""If the form is a progn form, each of its body
forms is sequentially
processed as a top level form in the same processing
mode."""
(and then:)
"""If the form is an eval-when form, it is handled
according to the next figure:
CT LT E Mode Action New Mode
----------
[....]
Yes No --- --- Evaluate ---
"""
But 3 and 5 shouldn't be printed because:
"""Otherwise, the form is a top level form that is
not one of the special cases."""
(this applies to let and defun respectively, then:)
""" In compile-time-too mode, the compiler first
evaluates the form in the evaluation environment and
then minimally compiles it. In not-compile-time mode,
the form is simply minimally compiled. All subforms are
treated as non-top-level forms."""
(so eval-when must not be "sequentially processed as
a top level form". But then:)
"""eval-when forms cause compile-time evaluation
only at top level. Both :compile-toplevel and
:load-toplevel situation specifications are ignored for
non-top-level forms."""
2) In prompt [64], when loading the previously compiled
code, clisp
prints 1 and 3. Again, 1 is right but 3 shouldn't be
printed. Curiously, 6 is not being printed here,
that's right.
3) But then, 6 is printed when loading the source file,
in prompt [65]. This is bad even if we consider that
:load-toplevel applies to loading of source code (for
the same reasons as before). But anyway, it doesn't:
"""The use of the situations :compile-toplevel (or
compile) and :load-toplevel (or load) controls whether
and when evaluation occurs when eval-when appears as a
top level form in code processed by compile-file"""
References:
Hyperspec:
Special Operator EVAL-WHEN
3.2.3.1 Processing of Top Level Forms
Code:
(progn
(eval-when (:load-toplevel)
(print 1)))
(progn ()
(eval-when (:compile-toplevel)
(print 2)))
(let ()
(eval-when (:load-toplevel)
(print 3)))
(let ()
(eval-when (:compile-toplevel)
(print 4)))
(defun foo ()
(eval-when (:compile-toplevel)
(print 5)))
(defun foo ()
(eval-when (:load-toplevel)
(print 6)))
[63]> (compile-file "/tmp/test-eval.lisp")
Compiling file /tmp/test-eval.lisp ...
2
4
5
Compilation of file /tmp/test-eval.lisp is finished.
0 errors, 0 warnings
#P"/tmp/test-eval.fas" ;
NIL ;
NIL
[64]> (load "/tmp/test-eval.fas")
;; Loading file /tmp/test-eval.fas ...
1
3
;; Loading of file /tmp/test-eval.fas is finished.
T
[65]> (load "/tmp/test-eval.lisp")
;; Loading file /tmp/test-eval.lisp ...
5
;; Loading of file /tmp/test-eval.lisp is finished.
T
Have luck,
CarlosP
Logged In: YES
user_id=5735
thank you for your bug report.
the bug has been fixed in the CVS tree.
you can either wait for the next release (recommended)
or check out the current CVS tree (see http://clisp.cons.org\)
and build CLISP from the sources (be advised that between
releases the CVS tree is very unstable and may not even build
on your platform).