From: William Harold Newman <william.newman@ai...> - 2002-12-09 13:39:06
On Sun, Dec 08, 2002 at 01:15:36PM -0700, Kevin Rosenberg wrote:
> Neil Schemenauer wrote:
> > > (setq *print-level* 3)
> > >
> > > will give you ACL output.
> > Is there a good reason this is not used for the read-eval-print loop?
> > As a new Lisp user, having SBCL spit out megabytes of text to my *sbcl*
> > buffer and crash XEmacs was a nasty surprise.
ANSI specifies that the initial values of *PRINT-LEVEL*,
*PRINT-LENGTH*, and *PRINT-CIRCLE* are NIL. (It's in the HyperSpec
pages for *PRINT-LEVEL*, *PRINT-LENGTH*, and *PRINT-CIRCLE*.) So we do
it that way.
Incidentally, I think ANSI probably made the right decision here. As
other people have said, this is easy to customize, so the only
question is what to do for new users who don't know about these
variables. New users could be surprised to get endless output (and
even more surprised when their environment handles endless output by
crashing) but at least they should be able to understand what
happened. The alternative of having the system do
* '(1 (2 (3 (4 (5)))) 6 7 8 9 10)
(1 (2 (3 #)) 6 ...)
has the disadvantage that when a user asked the printer to do
something reasonable, it would do something strange that the the user
wouldn't be able to figure it out for himself without hunting through
the entire manual chapter on the printer.
(So then, why do we still use non-NIL default values of *PRINT-LEVEL*
and *PRINT-LENGTH* in the debugger? Good question. This behavior is
left over from CMU CL, and probably from Spice Lisp too. The user
doesn't generally plan to get dropped into the debugger, and having a
programming error which drops him into the debugger then cause
unexpected infinite output would probably be considered bad. And it's
not all that satisfying to fix it, since the whole question of what to
do with printer/reader variables in the debugger highlights the way
that global variables (instead of e.g. per-stream attributes) are not
fundamentally a very good way to control things. So I'd probably
accept a patch to ANSIfy the debugger's default behavior, it would not
be without trepidation...)
William Harold Newman <william.newman@...>
hoping to beat the odds since 1972
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C