Hi All,
I don't know how to get the full expansion of a very long list, main
part of which are represented by "..." , even if I write the list to a
file. Is any information lost? Is it possible to retain the whole list
using a "big container"?
Sometimes, part of a string are represented by "# #". What's the
difference between "..." and "# #"?
Could anybody give me some hints?
CL-USER> (setq *parse* '(kk djj akk (kkk ddjdjfa) kkdaj
djdjjdjdjfjjjjfjfj adf f ( d d ) ddd eeeeedf ddf e jj jiij kadkfk
jfddj dkk (dd d ((dd da ) ddda aa ) dd d d d d ajddfj
adjfjdjf dfafd adf d fa f d fa fe f fa d fa f ad f af af ad f adf
a f asdf a f a f a ( d d a f ds f ) df d a ( d da f))))
CL-USER> *parse*
(KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
DDD ...)
CL-USER> (pprint *parse*)
(KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
DDD ...)
; No value
CL-USER> (with-open-file (stream "output.txt" :direction :output)
(format stream "~A~%" *parse* ))
output.txt:
(KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
DDD ...)
Thanks.
On Jan 8, 9:31 am, normanj <·······@gmail.com> wrote:
> I don't know how to get the full expansion of a very long list, main
> part of which are represented by "..." , even if I write the list to a
> file. Is any information lost? Is it possible to retain the whole list
> using a "big container"?
>
> CL-USER> *parse*
> (KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
> DDD ...)
It's only the way Lisp prints stuff, so you're not overwhelmed by huge
lists. Doesn't ruin the data or anything, as you'll see if you iterate
through those lists.
;; Print lists in their entirety from now on
(setf *print-level* nil
*print-length* nil)
Explained:
http://www.lisp.org/HyperSpec/Body/var_stprint-l_int-lengthst.html
Tayssir
From: Thomas A. Russ
Subject: Re: newbie question: how to get the full expansion of a long list?
Date:
Message-ID: <ymi7iihsffk.fsf@blackcat.isi.edu>
Tayssir John Gabbour <············@googlemail.com> writes:
> On Jan 8, 9:31 am, normanj <·······@gmail.com> wrote:
>
> It's only the way Lisp prints stuff, so you're not overwhelmed by huge
> lists. Doesn't ruin the data or anything, as you'll see if you iterate
> through those lists.
>
> ;; Print lists in their entirety from now on
> (setf *print-level* nil
> *print-length* nil)
>
> Explained:
> http://www.lisp.org/HyperSpec/Body/var_stprint-l_int-lengthst.html
Also, be aware that some lisps (Allegro Common Lisp, for example) have a
separate set of printer control variables for their top level REPL loop
that may also need to be set in order for interactive printing to work
as you might expect.
--
Thomas A. Russ, USC/Information Sciences Institute
P� Thu, 10 Jan 2008 19:28:47 +0100, skrev Thomas A. Russ
<···@sevak.isi.edu>:
> Tayssir John Gabbour <············@googlemail.com> writes:
>
>> On Jan 8, 9:31 am, normanj <·······@gmail.com> wrote:
>>
>> It's only the way Lisp prints stuff, so you're not overwhelmed by huge
>> lists. Doesn't ruin the data or anything, as you'll see if you iterate
>> through those lists.
>>
>> ;; Print lists in their entirety from now on
>> (setf *print-level* nil
>> *print-length* nil)
>>
>> Explained:
>> http://www.lisp.org/HyperSpec/Body/var_stprint-l_int-lengthst.html
>
> Also, be aware that some lisps (Allegro Common Lisp, for example) have a
> separate set of printer control variables for their top level REPL loop
> that may also need to be set in order for interactive printing to work
> as you might expect.
>
Not sure this is relevant but I thought I'd mention the two variables I
mess with most often.
*print-pretty* determines whether the default is to pretty print. Can have
a dramatic negative influence on performance if enabled. SBCL and CMUCL
has this set to t by default while LispWorks has it set to nil. This can
be a real gotcha with performance degradation as much as 10 times for file
write. (you can always explicitly pprint a expression)
*read-eval* determines wherther #. forms are evaluated. Set this to nil if
reading something from a webpage or be ready for potential insertion
attacks. You might want to consider disabling it for file reads as well.
--------------
John Thingstad
On Jan 8, 2:31 am, normanj <·······@gmail.com> wrote:
> I don't know how to get the full expansion of a very long list,
> main part of which are represented by "..."
> CL-USER> *parse*
> (KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
> DDD ...)
> CL-USER> (pprint *parse*)
> (KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
> DDD ...)
As TJG said, the tree is still there, so you can do whatever you
want with it. Also, sbcl is printing the whole tree just fine.
What does (format t "~A~%" *parse*) do on your system?
--Dan
www.prairienet.org/~dsb/
From: Kent M Pitman
Subject: Re: newbie question: how to get the full expansion of a long list?
Date:
Message-ID: <ulk70skeo.fsf@nhplace.com>
normanj <·······@gmail.com> writes:
> Hi All,
Hi.
> I don't know how to get the full expansion of a very long list,
It's not an expansion. The list is always there. The terminology you seek
is "how to get the list not to print in abbreviated fashion", I think.
> main part of which are represented by "..."
I assume here you mean this is how it's displayed. I personally think of
the representation of a list as the part inside the machine. You might
mean the "printed representation" (which is a kind of marshaling or
serializing of the list into a textual form), but in that case I'd add the
extra word "printed" to clarify.
> , even if I write the list to a file.
Where you write it to is not generally relevant. It's the fact of the
printing that does it.
> Is any information lost?
If you don't write it in full format it is.
You're probably looking for these printer control variables:
*PRINT-LEVEL*, *PRINT-LENGTH*
http://www.lispworks.com/documentation/HyperSpec/Body/v_pr_lev.htm
The "..." is controlled by *PRINT-LENGTH*.
Note also that using WITH-STANDARD-IO-SYNTAX will bind these to
reasonable values. See
http://www.lispworks.com/documentation/HyperSpec/Body/m_w_std_.htm
> Is it possible to retain the whole list using a "big container"?
I have no idea what this is about, but this is why you should be careful
with your terminology. Maybe you're asking whether you could represent
the list differently to avoid this, and the answer is no. It's not about
how the list is represented, it's about the dynamic state of Lisp at the
time of printing, and that's controlled by *print-length* and *print-level*
and the various other printer control variables (see WITH-STANDARD-IO-SYNTAX
for a list of them).
> Sometimes, part of a string are represented by "# #".
Abbreviation does not occur in strings. Maybe you mean you printed the
list to a string and some of its elements came out that way? That's done
by the printer according to *PRINT-LEVEL*.
> What's the
> difference between "..." and "# #"?
(foo (bar) baz)
will be printed as (foo ...) if it is length-abbreviated to 1
and as (foo # baz) if it is depth-abbreviated to 1.
> Could anybody give me some hints?
Does the above help?
> CL-USER> (setq *parse* '(kk djj akk (kkk ddjdjfa) kkdaj
> djdjjdjdjfjjjjfjfj adf f ( d d ) ddd eeeeedf ddf e jj jiij kadkfk
> jfddj dkk (dd d ((dd da ) ddda aa ) dd d d d d ajddfj
> adjfjdjf dfafd adf d fa f d fa fe f fa d fa f ad f af af ad f adf
> a f asdf a f a f a ( d d a f ds f ) df d a ( d da f))))
>
> CL-USER> *parse*
> (KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
> DDD ...)
Look at the value of *print-level* here. If it is non-NIL, probably your
lisp (or your lisp init file) sets it to that by default. You can change
it. In an application, you should bind it to a value your application wants.
> CL-USER> (pprint *parse*)
> (KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
> DDD ...)
Yes, the pretty printer looks at the same variable.
> ; No value
> CL-USER> (with-open-file (stream "output.txt" :direction :output)
> (format stream "~A~%" *parse* ))
>
> output.txt:
> (KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
> DDD ...)
Whether you are printing to a file doesn't matter, except that if you
do print to a file and expect to get it later, you'll lose.
There's an example of the right thing in
http://www.lispworks.com/documentation/HyperSpec/Body/m_w_std_.htm
It says:
(with-open-file (file pathname :direction :output)
(with-standard-io-syntax
(print data file)))
;;; ... Later, in another Lisp:
(with-open-file (file pathname :direction :input)
(with-standard-io-syntax
(setq data (read file))))
Thank you, everybody!
Thank you, Kent! I'm really appreciate it. The answer is perfect.
On Jan 8, 5:04 am, Kent M Pitman <······@nhplace.com> wrote:
> normanj <·······@gmail.com> writes:
> > Hi All,
>
> Hi.
>
> > I don't know how to get the full expansion of a very long list,
>
> It's not an expansion. The list is always there. The terminology you seek
> is "how to get the list not to print in abbreviated fashion", I think.
>
> > main part of which are represented by "..."
>
> I assume here you mean this is how it's displayed. I personally think of
> the representation of a list as the part inside the machine. You might
> mean the "printed representation" (which is a kind of marshaling or
> serializing of the list into a textual form), but in that case I'd add the
> extra word "printed" to clarify.
>
> > , even if I write the list to a file.
>
> Where you write it to is not generally relevant. It's the fact of the
> printing that does it.
>
> > Is any information lost?
>
> If you don't write it in full format it is.
>
> You're probably looking for these printer control variables:
>
> *PRINT-LEVEL*, *PRINT-LENGTH*
> http://www.lispworks.com/documentation/HyperSpec/Body/v_pr_lev.htm
>
> The "..." is controlled by *PRINT-LENGTH*.
>
> Note also that using WITH-STANDARD-IO-SYNTAX will bind these to
> reasonable values. See
> http://www.lispworks.com/documentation/HyperSpec/Body/m_w_std_.htm
>
> > Is it possible to retain the whole list using a "big container"?
>
> I have no idea what this is about, but this is why you should be careful
> with your terminology. Maybe you're asking whether you could represent
> the list differently to avoid this, and the answer is no. It's not about
> how the list is represented, it's about the dynamic state of Lisp at the
> time of printing, and that's controlled by *print-length* and *print-level*
> and the various other printer control variables (see WITH-STANDARD-IO-SYNTAX
> for a list of them).
>
> > Sometimes, part of a string are represented by "# #".
>
> Abbreviation does not occur in strings. Maybe you mean you printed the
> list to a string and some of its elements came out that way? That's done
> by the printer according to *PRINT-LEVEL*.
>
> > What's the
> > difference between "..." and "# #"?
>
> (foo (bar) baz)
>
> will be printed as (foo ...) if it is length-abbreviated to 1
> and as (foo # baz) if it is depth-abbreviated to 1.
>
> > Could anybody give me some hints?
>
> Does the above help?
>
> > CL-USER> (setq *parse* '(kk djj akk (kkk ddjdjfa) kkdaj
> > djdjjdjdjfjjjjfjfj adf f ( d d ) ddd eeeeedf ddf e jj jiij kadkfk
> > jfddj dkk (dd d ((dd da ) ddda aa ) dd d d d d ajddfj
> > adjfjdjf dfafd adf d fa f d fa fe f fa d fa f ad f af af ad f adf
> > a f asdf a f a f a ( d d a f ds f ) df d a ( d da f))))
>
> > CL-USER> *parse*
> > (KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
> > DDD ...)
>
> Look at the value of *print-level* here. If it is non-NIL, probably your
> lisp (or your lisp init file) sets it to that by default. You can change
> it. In an application, you should bind it to a value your application wants.
>
> > CL-USER> (pprint *parse*)
> > (KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
> > DDD ...)
>
> Yes, the pretty printer looks at the same variable.
>
> > ; No value
> > CL-USER> (with-open-file (stream "output.txt" :direction :output)
> > (format stream "~A~%" *parse* ))
>
> > output.txt:
> > (KK DJJ AKK '(KKK DDJDJFA) KKDAJ DJDJJDJDJFJJJJFJFJ ADF F (D D)
> > DDD ...)
>
> Whether you are printing to a file doesn't matter, except that if you
> do print to a file and expect to get it later, you'll lose.
> There's an example of the right thing in
> http://www.lispworks.com/documentation/HyperSpec/Body/m_w_std_.htm
> It says:
>
> (with-open-file (file pathname :direction :output)
> (with-standard-io-syntax
> (print data file)))
>
> ;;; ... Later, in another Lisp:
>
> (with-open-file (file pathname :direction :input)
> (with-standard-io-syntax
> (setq data (read file))))