From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: Display of large structures by LISP interpreter
Date: 1997/03/05
Message-ID: <3066581128915796@naggum.no>#1/1
X-Deja-AN: 223338978
References: <5fk2cf$fd$2@roadkill.scms.rgu.ac.uk>
mail-copies-to: never
Organization: Naggum Software; +47 2295 0313; http://www.naggum.no
Newsgroups: comp.lang.lisp


* Robin Boswell
| Can anyone tell me if it is possible to prevent the LISP interpreter from
| truncating returned values, when these happen to be long lists or other
| large structures.  I am aware of the effect of *print-length* and
| *print-level* on the (print) function, but these don't seem to effect the
| LISP reader/interpreter itself, e.g.
| 
| USER(1): *print-length*
| NIL ;; So (print) won't truncate, but ...
| 
| USER(2): (setq foo '(1 2 3 4 5 6 7 8 9 10 11 12 13 14))
| (1 2 3 4 5 6 7 8 9 10 ...) ;; foo still gets truncated

I see from your prompt that you're using Allegro Common Lisp.  (it wouldn't
hurt to say which Lisp implementation, version, and platform you're using.)

common-lisp:*print-length* and common-lisp:*print-level* are bound over the
printing of the returned value(s) in the top-level loop to the values of
top-level:*print-length* and top-level:*print-level*.  this is described in
the User Guide on page 4-16.  here's a session that shows another possibly
unexpected property of these variables.

    user(1): (require :loop)
    ; Fast loading from bundle code/loop.fasl.
    t
    user(2): (apropos "*print-le")
    *print-length*      value: 4
    *print-level*       value: 3
    tpl:*print-length*  value: 10
    tpl:*print-level*   value: 5
    user(3): (dolist (sym (apropos-list "*print-le"))
	       (print sym)
	       (prin1 (symbol-value sym)))

    top-level:*print-level* 5
    top-level:*print-length* 10
    *print-level* nil
    *print-length* nil
    nil
    user(4): (loop for i upto 10 collect i)
    (0 1 2 3 4 5 6 7 8 9 ...)
    user(5): (setq top-level:*print-length* nil)
    nil
    user(6): (loop for i upto 10 collect i)
    (0 1 2 3 4 5 6 7 8 9 10)

why are the values reported by `apropos' not the values of the symbols?
because `apropos' binds them when printing so the printed values of the
symbols won't be too large.

#\Erik
-- 
if you think big enough, you never have to do it