Symbolics DRIBBLE compatibility?

[Barry Margolin <barmar@Think.COM>]

I am wondering about the compatibility of Symbolics's implementation of
DRIBBLE with CLtL.  According to the Symbolics documentation (page 680
of Volume 2A of the Encyclopedia Symbolicorum), they believe that they
are compatible.

The way the Symbolics (DRIBBLE pathname) works is that it binds
*STANDRD-INPUT, *STANDARD-OUTPUT*, etc. to the dribble stream and then
calls the Lisp read-eval-print loop.  It also sets up a catch-tag.
(DRIBBLE) throws to the tag, and appropriate unwind-protects close the
dribble stream.

What does this mean as far as compatibility is concerned?  Consider the
following form:

(progn (dribble "filename")
       (print 'foo)
       (dribble))

 From reading CLtL one would assume that this would print put FOO into
the file.  On a Symbolics system the first DRIBBLE starts recording I/O
and then goes to a new r-e-p loop; the PRINT doesn't get executed until
the user does (dribble), and then the second DRIBBLE complains that
output isn't being recorded.

Or how about typing:

(dribble "filename)
(progn (print 'foo)
       (dribble)
       (print 'bar))

The second PRINT will never get executed, because the (dribble) throws
out of the PROGN.

Finally, you could really get screwed if you start dribbling, do
something that gets you into the debugger, and decide to stop dribbling;
you will lose your debugger session.  This doesn't actually happen
because Symbolics disables dribbling when you go into the debugger or
when you get a new r-e-p loop with the Suspend key, so (dribble) just
says that output isn't being recorded and does nothing else.  (The fact
that debugger and break loop I/O isn't dribbled is another point of
contention I have.)

CLtL doesn't say a whole lot about DRIBBLE.  In particular, it doesn't
say what the return value is, but that doesn't mean that it is allowed
for (dribble) not to return, does it?  What do other Common Lispers
think?

                                                barmar