Display of large structures by LISP interpreter
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
Thanks,
Robin Boswell.
Mike McDonald
In article <5fk2cf$fd$2...@roadkill.scms.rgu.ac.uk>,
I've found that a lot of toplevel loops like to bind *print-length*
themselves. I get around it by making an explicit call to print:
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
USER(3): (print 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 ...)
Annoying but works when I really need to see the whole thing, like *features*.
Mike McDonald
mik...@engr.sgi.com
Erik Naggum
* 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
Erik Naggum
* Mike McDonald
| Annoying but works when I really need to see the whole thing, like
| *features*.
I use (map () #'print *features*) to do that.
`pprint' is probably better than `print' if you call a single function.
unlike `print', `pprint' does not return its argument value.
William Paul Vrotney
In article <5fk2cf$fd$2...@roadkill.scms.rgu.ac.uk> r...@scms.rgu.ac.uk (Robin Boswell) writes:
> X-Newsreader: TIN [version 1.2 PL2]
>
> 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
>
> Thanks,
>
> Robin Boswell.
>
You could get around it by writing your own REP loop
(defun myloop ()
(let ((*print-length* nil))
(loop (print (eval (read))))))
--
William P. Vrotney - vro...@netcom.com
David B. Lamkins
--Cyberdog-AltBoundary-000C6503
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
> 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
>
You didn't say which system you're using. Try apropos to see whether
there's a print-length variable for the toploop.
---------------------------------------------------
David B. Lamkins, http://www.teleport.com/~dlamkins/
---------------------------------------------------
--Cyberdog-AltBoundary-000C6503
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-000C6503"
Content-Transfer-Encoding: 7bit
--Cyberdog-MixedBoundary-000C6503
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<SMALLER><X-FONTSIZE><PARAM>10</PARAM><FIXED><FONTFAMILY><PARAM>Courier=
</PARAM>> 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))
</FONTFAMILY></FIXED></X-FONTSIZE></SMALLER><SMALLER><X-FONTSIZE><PARAM=
>10</PARAM><FONTFAMILY><PARAM>Geneva</PARAM>></FONTFAMILY></X-FONTSIZE>=
</SMALLER><SMALLER><X-FONTSIZE><PARAM>10</PARAM><FIXED><FONTFAMILY><PAR=
AM>Courier</PARAM>(1 2 3 4 5 6 7 8 9 10 ...) ;; foo still gets
truncated
</FONTFAMILY></FIXED></X-FONTSIZE></SMALLER><SMALLER><X-FONTSIZE><PARAM=
>10</PARAM><FONTFAMILY><PARAM>Geneva</PARAM>>
You didn't say which system you're using. Try apropos to see whether
there's a print-length variable for the toploop.
---------------------------------------------------
David B. Lamkins, http://www.teleport.com/~dlamkins/
---------------------------------------------------
</FONTFAMILY></X-FONTSIZE></SMALLER>
--Cyberdog-MixedBoundary-000C6503--
--Cyberdog-AltBoundary-000C6503--
Larry Hunter
r...@scms.rgu.ac.uk (Robin Boswell) writes:
> 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
>
This looks like ACL, where tpl:*print-length* shadows *print-level* at the
top level. From the ACL documentation:
DESCRIPTION
This variable performs the same function as the COMMON LISP variable
*print-length*, except that it applies to forms printed by the top
level. It controls the length when printing complex structures.
Note that there is no direct connection between the LISP package vari-
ables and the top-level variables (that is changing one does not affect
the other) and that their initial values are different. The initial
value of this variable is 10.
EXAMPLES
;; In this example, we change the value of TOPLEVEL:*PRINT-LENGTH*
;; from 10 to 15 so that we can see the entire list that the
;; LET form is returning.
<cl> top-level:*print-length*
10
<cl> (let ((result nil))(dotimes (i 15 result)
(push i result)))
(14 13 12 11 10 9 8 7 6 5 ...)
<cl> (setq top-level:*print-length* 15)
15
<cl> (let ((result nil))(dotimes (i 15 result)
(push i result)))
(14 13 12 11 10 9 8 7 6 5 4 3 2 1 0)
<cl>
Larry
--
Lawrence Hunter, PhD.
National Library of Medicine phone: +1 (301) 496-9303
Bldg. 38A, 9th fl, MS-54 fax: +1 (301) 496-0673
Bethesda. MD 20894 USA email: hun...@nlm.nih.gov
Warning: sending unsolicited email advertising to this address violates US
Code Title 47, Sec.227, incurring a liability of at least $500 per incident.
Rainer Joswig
In article <rb7mjky...@work.csb>, Larry Hunter <hun...@work.csb> wrote:
> r...@scms.rgu.ac.uk (Robin Boswell) writes:
>
> > 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
> >
>
> This looks like ACL, where tpl:*print-length* shadows *print-level* at the
> top level. From the ACL documentation:
See also the documentation on TPL:SETQ-DEFAULT .
You might want in your init file something like:
(tpl:setq-default *print-length* 40)