Subject: [clisp-list] Current CVS observations

From: Christophe Rhodes <[email-masked]>
Date: Mon Mar 24 05:22:10 2003

Hi,

I've just tried out CLISP's current CVS on x86 linux, in the hope that
it's close enough to the beta to be useful feedback.  Two
observations:

1. Building with --with-debug seemed to cause problems.  The testsuite
   hung, seemingly for ever, on (RATIONALIZE PI); investigating
   further revealed something a bit weird going on:

   [1]> pi           
   0.00282743338823081391L0
   [2]> (exp 1.0)
   5.0E-7
   [3]> (exp 1.0d0)
   2.718281828459045d0

2. Without --with-debug, the build is more successful, though the
   testsuite target still fails.  I then tried to build sbcl on it,
   but it would appear that clisp detects assignments to internal
   symbols in other packages, which happens a lot in sbcl's build:

   WARNING in (PROGN (DEF!MACRO !DEF-BOOLEAN-ATTRIBUTE # ...) (DEFUN GUTS-OF-!DEF-BOOLEAN-ATTRIBUTE-SETTER # ...) ...)-10-1-2 in lines 149..236 :
   SETQ: assignment to the internal special symbol  SB!IMPL::*DELAYED-DEF!MACROS*

   A full compile-time warning sets the FAILUREP return value from
   COMPILE-FILE to T, which is interpreted by the build scripts as an
   actual failure.  Is there any way to lessen the impact of this
   warning, either by weakening it to a STYLE-WARNING or by turning it
   off altogether?

Cheers,

Christophe
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

---

From: Sam Steingold <[email-masked]>
Date: Mon Mar 24 07:50:02 2003

> * In message <[email-masked]>
> * On the subject of "[clisp-list] Current CVS observations"
> * Sent on Mon, 24 Mar 2003 13:20:20 +0000
> * Honorable Christophe Rhodes <[email-masked]> writes:
>

I do not observe this:

[1]> pi
3.1415926535897932385L0
[2]> (exp 1.0)
2.7182817
[3]> (RATIONALIZE PI)
8717442233/2774848045

>    warning, either by weakening it to a STYLE-WARNING or by turning it

this was a bug, fixed now: the warning should be signaled only when
the (SYMBOL-PACKAGE var) is locked.

please do cvs up and try again.
if you still observe the numerical problem, please try to debug them.
(run under gdb and see where RATIONALIZE hangs)

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
(let((a'(list'let(list(list'a(list'quote a)))a)))`(let((a(quote ,a))),a))

---

From: Christophe Rhodes <[email-masked]>
Date: Mon Mar 24 08:15:14 2003

> please do cvs up and try again.

Thank you; that issue is now resolved... I still seem to get some
similar messages when I do pretty-printing-intensive stuff, but I
haven't chased it down yet.

> (run under gdb and see where RATIONALIZE hangs)

This time, when I tried building with --with-debug, the build seemed
to hang while running interpreted.mem to compile the world... when I
attached gdb to it, it seemed to be in the process of trying to print
a backtrace(?)

In any case, here is another problem in the non-debug image:

[8]> (defmacro foo (&key (bar (error "foo"))) ())
FOO
[9]> (foo)
*** - foo               ; as expected
1. Break [10]> 
[11]> (foo :bar 1)

*** - foo               ; not as expected

A relatively common idiom I've seen is to do
  (defmacro deffoo (&key (frob (error "missing argument"))
                         other-key))
to give a handy defining interface where some keywords are
required...

Cheers,

Christophe

---

From: Sam Steingold <[email-masked]>
Date: Tue Mar 25 12:11:24 2003

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] Current CVS observations"
> * Sent on Mon, 24 Mar 2003 16:13:31 +0000

world?  you mean "-c compiler.lisp"?
this can take a long time.

> attached gdb to it, it seemed to be in the process of trying to print

weird.

> *** - foo               ; not as expected

fixed, thanks.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Save your burned out bulbs for me, I'm building my own dark room.

---

From: Christophe Rhodes <[email-masked]>
Date: Wed Mar 26 03:13:01 2003

> this can take a long time.

OK, with --with-debug from a clean CVS checkout from yesterday, I'm
back to PI behaving weirdly:

csr21@mu:~/misc-cvs/clisp$ xxx/lisp.run -M xxx/lispinit.mem 
STACK depth: 16363
SP depth: 67109992
[...]
[1]> pi
0.00282743338823081391L0
[2]> (rationalize pi)
[... apparent hang ...]
1. Break [4]> 1.0L0
9.000000000000000L-5

So maybe long-float stuff is broken?  If it helps, gcc was 2.95.4 from
Debian, and clisp was configured with 
./configure --with-debug --build xxx
Let me know if there's anything else you'd like me to try on this one.

>> *** - foo               ; not as expected

Thanks.  I'll try again (with a non-debug build) and see what happens
now :-)

Cheers,

Christophe

---

From: Christophe Rhodes <[email-masked]>
Date: Wed Mar 26 04:19:14 2003

> Thanks.  I'll try again (with a non-debug build) and see what happens

OK, some more tidbits:

Compiling (and not loading!) a file with the following contents
  (let ()
    (defmacro foo () 'nil))
appears nonetheless to define the FOO macro in the REPL.  This strikes
me as positively weird.

Compiling a file containing
  (defstruct foo a)
  (defmethod print-object ((x foo) stream)
    (pprint-logical-block (stream nil)
      (print-unreadable-object (x stream :type t :identity t)
        (print (foo-a x) stream))))
leads to two compiler messages, one of which causes a continuable
error because of package locks:
  WARNING in (DEFMETHOD PRINT-OBJECT (# STREAM) ...)-2-1-1-1 in lines 2..5 :
  SETQ: assignment to the internal special symbol SYSTEM::*PRIN-LEVEL*
  WARNING in (DEFMETHOD PRINT-OBJECT (# STREAM) ...)-2-1-1-1 in lines 2..5 :
  variable SYSTEM::OBJ is not used.
  Misspelled or missing IGNORE declaration?

clisp now compiles the first stage of sbcl to completion... I'll try
running it soon, but there was another surprise: that
MULTIPLE-VALUE-BIND was a special operator.  I guess that is
conforming if you provide the macro definition?  It surprised me, is
all -- why do you do that?

Anyway, thanks for the help,

Cheers,

Christophe

---

From: Christophe Rhodes <[email-masked]>
Date: Wed Mar 26 04:44:11 2003

> appears nonetheless to define the FOO macro in the REPL.  This strikes

And yet slightly more weirdness:

Compiling the following:
  (let ()
    (eval-when (:compile-toplevel :load-toplevel :execute)
      (defmacro foo () 'nil)))
does not lead to a FOO macro being present after compilation.
However, it doesn't lead to a FOO macro being present after loading
the resulting .fas file, either.  Loading the source file works as
expected.

Cheers,

Christophe

---

From: Sam Steingold <[email-masked]>
Date: Wed Mar 26 06:55:14 2003

> * In message <[email-masked]>
> * Sent on Wed, 26 Mar 2003 11:10:56 +0000

what did you snip?
do you have a ~/.clisprc?

> Let me know if there's anything else you'd like me to try on this one.

(float pi 1d0)
(sin pi)

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
I don't have an attitude problem. You have a perception problem.

---

From: Christophe Rhodes <[email-masked]>
Date: Wed Apr 2 01:40:30 2003

Sorry it's taken so long to get back to you:

> do you have a ~/.clisprc?

I have no ~/.clisprc -- the only snippage was the normal clisp herald.

>> Let me know if there's anything else you'd like me to try on this one.

[1]> (float pi 1d0)
3.141592653589793d0
[2]> pi
0.00282743338823081391L0
[3]> (sin pi)
-5.0165576136843360246L-20
[4]> (cos pi)
-9.000000000000000L-5
[5]> (tan pi)
5.0165576136843360246L-20

Hope that helps...

Cheers,

Christophe

---

From: Sam Steingold <[email-masked]>
Date: Wed Apr 2 07:14:19 2003

> * In message <[email-masked]>
> * On the subject of "Re: Current CVS observations"
> * Sent on Wed, 02 Apr 2003 10:37:52 +0100

it appears that _printing_ of long floats is broken, rather than
_arithmetics_.  Could you please check that?
e.g.,

(float (cos pi) 1d0) ==> -1d0 ?

&c&c

btw, what is *WARN-ON-FLOATING-POINT-CONTAGION*?

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
War doesn't determine who's right, just who's left.

---

From: Christophe Rhodes <[email-masked]>
Date: Wed Apr 2 07:31:57 2003

> (float (cos pi) 1d0) ==> -1d0 ?

Yup.

[1]> *warn-on-floating-point-contagion*
T
[2]> (float (cos pi) 1.0d0)
-1.000000000000000d0

Cheers,

Christophe

---

From: Sam Steingold <[email-masked]>
Date: Wed Apr 2 15:32:43 2003

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] Re: Current CVS observations"
> * Sent on Wed, 02 Apr 2003 16:28:22 +0100

The bad news is that nobody can reproduce this bug, so you are on your
own. 

The good news is that the bug in lisp, not C, so all you need to look
at is src/floatprint.lisp

The bad news is that the comments (and some variable names!) are in
German.

The good news is that there are a _lot_ of comments there, and the file
is just over 400 lines.

So just go there and try to figure out what is bad.
you can load the source with
$ clisp -E utf-8 -i floatprint.lisp
and step through the print functions.

Thanks!

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
I don't want to be young again, I just don't want to get any older.

---

From: Christophe Rhodes <[email-masked]>
Date: Thu Apr 3 01:46:40 2003

> The bad news is that nobody can reproduce this bug, so you are on your

Wow, cool!  I wonder how on earth I've managed this.

> The bad news is that the comments (and some variable names!) are in

:-)

> Thanks!

I'll give it a try -- I'll try to have a look at it on my travels.

I hesitate to ask, but has there been any progress on the other two
issues I reported?  (in case they're lost, they related to EVAL-WHEN
:EXECUTE not being executed when it's not at top-level, and use of
print-logical-block setting a variable (*PRIN-LEVEL*?) in a locked
package.

Cheers,

Christophe

---

From: Sam Steingold <[email-masked]>
Date: Thu Apr 3 06:50:59 2003

> * In message <[email-masked]>
> * Sent on Thu, 03 Apr 2003 10:44:49 +0100

thanks.

> :EXECUTE not being executed when it's not at top-level, and use of

I am afraid I don't recall this.

> print-logical-block setting a variable (*PRIN-LEVEL*?) in a locked

please try the appended patch.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
(lisp programmers do it better)

--- pprint.lisp.~1.8.~	2002-11-28 15:40:13.000000000 -0500
+++ pprint.lisp	2003-04-03 09:43:39.000000000 -0500
@@ -114,6 +114,7 @@
         (suf (gensym "PPLB-SUFF-")))
     `(let ((,pre ,prefix)
            (,suf ,suffix)
+           (*prin-level* (1+ *prin-level*))
            (*prin-line-prefix* ,per-line-prefix)
            (*prin-miserp*
             (and *print-miser-width*
@@ -159,7 +160,6 @@
                            (go pprint-logical-block-end))))
                       (pprint-exit-if-list-exhausted ()
                         '(unless obj (go pprint-logical-block-end))))
-             (incf *prin-level*)
              (when ,pre
                (write-string ,pre ,out)
                (pprint-indent :current 0 ,out))

---

From: Christophe Rhodes <[email-masked]>
Date: Thu Apr 3 07:40:56 2003

> please try the appended patch.

Thank you, that works much better.  I would send a diff in return, but
sourceforge appears to be playing up at this moment, so could I
suggest that 
  (declare (ignorable obj)) 
be added to the lambda in %PPRINT-LOGICAL-BLOCK, thusly:
  (lambda (,out obj)
    (declare (ignorable obj)) ; HERE
    (let ((,idx 0))
?  This would remove the other generated warning.

> I am afraid I don't recall this.

Consider a file with the following contents:
  (let ()
    (eval-when (:compile-toplevel :load-toplevel :execute)
      (print "foo")))
  (let ()
    (eval-when (compile load eval)
      (print "bar")))

I maintain that compiling this file should print nothing, and loading
it should print "foo" and "bar"; CMUCL, ACL and Lispworks agree with
me (I won't mention sbcl :-).  CLISP, however, prints "foo" neither on
compilation nor on loading, while printing "bar" both at compile-time
and on loading.

Looking at control.d, it would appear that the EVAL-WHEN there is very
CLTL1ish -- it seems to believe in EVAL and (NOT COMPILE) (and
Kexecute, which I would presume to mean :EXECUTE), but no logic for
handling LOAD/:LOAD-TOPLEVEL.

I believe the applicable paragraph from the CLHS page for EVAL-WHEN is
the following:

  The use of the situation :execute (or eval) controls whether
  evaluation occurs for other eval-when forms; that is, those that are
  not top level forms, or those in code processed by eval or
  compile. If the :execute situation is specified in such a form, then
  the body forms are processed as an implicit progn; otherwise, the
  eval-when form returns nil.

the EVAL-WHENs above are not top-level forms, as they are inside a LET
(the only forms preserving toplevelness being MACROLET,
SYMBOL-MACROLET, LOCALLY and PROGN), so since :EXECUTE/EVAL are
specified, I would expect their bodies to be executed at load time.

There are headache-inducing examples on the CLHS page for EVAL-WHEN,
the most pertinent of which is the first.

Cheers,

Christophe

---

From: Sam Steingold <[email-masked]>
Date: Thu Apr 3 12:54:18 2003

> * In message <[email-masked]>
> * Sent on Thu, 03 Apr 2003 16:34:29 +0100

   As expounded upon in the impnotes
   <http://clisp.cons.org/impnotes.html#eval-when>,
   in CLISP the deprecated situations COMPILE and LOAD are _NOT_
   equavalent to the new standard situations :COMPILE-TOPLEVEL and
   :LOAD-TOPLEVEL.
   We believe that this gives the users some extra functionality for no
   cost (those who want strict compliance probably do not use deprecated
   functionality anyway).
   Yes, this is a deviation from the standard.
   No, it is not controlled by `-ansi' (yet?).

that said, let us consider the following code:

(defvar *collector*)
(let ((forms nil))
  (dolist (c '(nil (:compile-toplevel)))
    (dolist (l '(nil (:load-toplevel)))
      (dolist (x '(nil (:execute)))
        (push `(eval-when (,@c ,@l ,@x)
                 (push '(,@c ,@l ,@x) *collector*))
              forms))))
  (dolist (c '(nil (:compile-toplevel)))
    (dolist (l '(nil (:load-toplevel)))
      (dolist (x '(nil (:execute)))
        (push `(let () (eval-when (,@c ,@l ,@x)
                         (push '(let ,@c ,@l ,@x) *collector*)))
              forms))))
  (with-open-file (o "eval-when-test.lisp" :direction :output
                     :if-exists :supersede)
    (dolist (f forms)
      (prin1 f o)
      (terpri o)))
  (let ((*collector* nil))
    (load "eval-when-test.lisp")
    (print *collector*))
  (let ((*collector* nil))
    (compile-file "eval-when-test.lisp")
    (print *collector*))
  (let ((*collector* nil))
    (load (compile-file-pathname "eval-when-test.lisp"))
    (print *collector*)))

what should the printout be?
I would appreciate it if you could raise this issue on c.l.l so that we
could get an authoritative answer that would close the discussion.

thanks.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Lottery is a tax on statistics ignorants.  MS is a tax on computer-idiots.

---

From: Christophe Rhodes <[email-masked]>
Date: Fri Apr 4 00:52:10 2003

>    No, it is not controlled by `-ansi' (yet?).

OK, fair enough.  I'm only tangentially interested in the COMPILE LOAD
EVAL situations, as it happens; I was just slightly perturbed by the
difference in behaviour.  I'm very interested in getting compliant
behaviour from :COMPILE-TOPLEVEL/:LOAD-TOPLEVEL/:EXECUTE.

>     (load "eval-when-test.lisp")

LOAD of source implies that the relevant top-level regime is :EXECUTE.
Therefore, for the EVAL-WHEN forms at toplevel, only those
combinations with :EXECUTE in the situations will be executed, so this
list starts with those toplevel forms with :EXECUTE.  For the
EVAL-WHEN forms not at top level, their execution on EVAL/LOAD is
again controlled by :EXECUTE, so again only those forms with :EXECUTE
in their situations will be executed, so the final list is:

((:execute) 
 (:load-toplevel :execute) 
 (:compile-toplevel :execute)
 (:compile-toplevel :load-toplevel :execute)
 (let :execute)
 (let :load-toplevel :execute)
 (let :compile-toplevel :execute)
 (let :compile-toplevel :load-toplevel :execute))

>     (compile-file "eval-when-test.lisp")

The situation controlling execution of top-level forms at COMPILE-FILE
time is :COMPILE-TOPLEVEL, so for the EVAL-WHENs at toplevel, only
those with :COMPILE-TOPLEVEL in their list of situations will be
executed.  EVAL-WHENs not at top-level are never executed at
COMPILE-FILE time (see CLHS 3.2.3), so the answer is

((:compile-toplevel)
 (:compile-toplevel :execute)
 (:compile-toplevel :load-toplevel)
 (:compile-toplevel :load-toplevel :execute))

>     (load (compile-file-pathname "eval-when-test.lisp"))

The situation controlling execution of toplevel EVAL-WHENs processed
by LOAD of COMPILE-FILE is :LOAD-TOPLEVEL, so the toplevel forms with
:LOAD-TOPLEVEL in their situations will be executed.  Non-toplevel
EVAL-WHENs with :EXECUTE (that being the only important situation for
non-toplevel EVAL-WHENs) will have been compiled to a PROGN, and
therefore EVAL-WHENs inside the LET with :EXECUTE on their situations
will also push onto *COLLECTOR*, so the printout from this one is:

((:load-toplevel)
 (:load-toplevel :execute)
 (:compile-toplevel :load-toplevel)
 (:compile-toplevel :load-toplevel :execute)
 (let :execute)
 (let :load-toplevel :execute)
 (let :compile-toplevel :execute)
 (let :compile-toplevel :load-toplevel :execute))

> could get an authoritative answer that would close the discussion.

I guess cll could get involved, but is there something in the above
that isn't clear?  The relevant passages from the CLHS are the
EVAL-WHEN Special Operator page and section 3.2.3 (and 3.2.3.1, though
I dunno if that isn't a bit confusing -- the cases above don't need
3.2.3.1 to be explained; the difficult ones involve nested eval-whens).

Cheers,

Christophe

---

From: Sam Steingold <[email-masked]>
Date: Fri Apr 4 08:12:36 2003

> * In message <[email-masked]>
> * Sent on Fri, 04 Apr 2003 09:50:38 +0100

CMUCL:

 ((:load-toplevel)

either your analysis is incorrect, or CMUCL is faulty too.

>  (:compile-toplevel :load-toplevel :execute))

no contest.

>  (let :compile-toplevel :load-toplevel :execute))

CMUCL & CLISP:

 ((:execute)
  (let :compile-toplevel :load-toplevel :execute)))

is it possible that you are confusing :execute and :load-toplevel?

> 3.2.3.1 to be explained; the difficult ones involve nested eval-whens).

this whole thing is confusing enough, IMNSHO.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Only adults have difficulty with child-proof caps.

---

From: Christophe Rhodes <[email-masked]>
Date: Fri Apr 4 08:40:08 2003

> is it possible that you are confusing :execute and :load-toplevel?

The printout I get from CMUCL, verbatim, from pasting in your code,
is:

; Loading #p"/usr/home/csr21/eval-when-test.lisp".

((:EXECUTE) (:LOAD-TOPLEVEL :EXECUTE) (:COMPILE-TOPLEVEL :EXECUTE)
 (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
 (LET :EXECUTE
   )
 (LET :LOAD-TOPLEVEL
   :EXECUTE)
 (LET :COMPILE-TOPLEVEL
   :EXECUTE)
 (LET :COMPILE-TOPLEVEL
   :LOAD-TOPLEVEL

; Python version 1.0, VM version Intel x86 on 04 APR 03 05:21:58 pm.
; Compiling: /usr/home/csr21/eval-when-test.lisp 04 APR 03 05:21:58 pm

; Byte Compiling Top-Level Form: 
; Byte Compiling Top-Level Form: 

; eval-when-test.x86f written.
; Compilation finished in 0:00:00.
   :EXECUTE)) 
((:COMPILE-TOPLEVEL) (:COMPILE-TOPLEVEL :EXECUTE)
 (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL) (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)) 
; Loading #p"/usr/home/csr21/eval-when-test.x86f".

((:LOAD-TOPLEVEL) (:LOAD-TOPLEVEL :EXECUTE) (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL)
 (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
 (LET :EXECUTE
   )
 (LET :LOAD-TOPLEVEL
   :EXECUTE)
 (LET :COMPILE-TOPLEVEL
   :EXECUTE)
 (LET :COMPILE-TOPLEVEL
   :LOAD-TOPLEVEL
   :EXECUTE)) 
((:LOAD-TOPLEVEL) (:LOAD-TOPLEVEL :EXECUTE) (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL)
 (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
 (LET :EXECUTE
   )
 (LET :LOAD-TOPLEVEL
   :EXECUTE)
 (LET :COMPILE-TOPLEVEL
   :EXECUTE)
 (LET :COMPILE-TOPLEVEL
   :LOAD-TOPLEVEL
   :EXECUTE))

It's a bit hard to read, I grant, but there are four separate lists
here.  The first, just below 
  ; Loading #p"/usr/home/csr21/eval-when-test.lisp".
corresponds to my "load of source" paragraph, and agrees with my
analysis. 

The second, corresponding to the compilation of the source, is
uncontroversial and agrees with my analysis.

The third and fourth are the same lists, once printed out by the
program and once as the return value from the program; again, the
presence of :LOAD-TOPLEVEL agrees with my analysis.  I don't
understand how you've got your results with CMUCL.  (for reference,
mine is 
  CMU Common Lisp release x86-linux 3.1.7 18d+ 18 January 2003 build 4523
as distributied by Debian Linux.

ACL's output is easier to read, as it happens; it says:

,---------------------
|; Loading /usr/home/csr21/eval-when-test.lisp
|
|((:EXECUTE) (:LOAD-TOPLEVEL :EXECUTE) (:COMPILE-TOPLEVEL :EXECUTE)
| (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (LET :EXECUTE)
| (LET :LOAD-TOPLEVEL :EXECUTE) (LET :COMPILE-TOPLEVEL :EXECUTE)
| (LET :COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)) 
|;;; Compiling file eval-when-test.lisp
|;;; Writing fasl file eval-when-test.fasla16
|Warning: No IN-PACKAGE form seen in
|         /usr/home/csr21/eval-when-test.lisp.  (Allegro Presto will be
|         ineffective when loading a file having no IN-PACKAGE form.)
|;;; Fasl write complete
|
|((:COMPILE-TOPLEVEL) (:COMPILE-TOPLEVEL :EXECUTE)
| (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL)
| (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)) 
|; Fast loading /usr/home/csr21/eval-when-test.fasla16
|
|((:LOAD-TOPLEVEL) (:LOAD-TOPLEVEL :EXECUTE)
| (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL)
| (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE) (LET :EXECUTE)
| (LET :LOAD-TOPLEVEL :EXECUTE) (LET :COMPILE-TOPLEVEL :EXECUTE)
| (LET :COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)) 
'---------------------

where I have elided the fourth (return value) list.

Cheers,

Christophe