I want to read from *standard-input* (user inputs) series lists
like the below
Input : (2 3) (3 2) (4 5) (7 9)
would it be made a big list ? ((2 3) (3 2) (4 5) (7 9))
or like C's cin in buffer, then reading in after next (read).
········@csie.ntu.edu.tw (�x���u) writes:
> I want to read from *standard-input* (user inputs) series lists
> like the below
>
> Input : (2 3) (3 2) (4 5) (7 9)
>
> would it be made a big list ? ((2 3) (3 2) (4 5) (7 9))
> or like C's cin in buffer, then reading in after next (read).
You have to say how you want to detect and end-of-record.
If you're just reading a single line and you want all the lists on
the line, then:
(defun read-a-line-of-lists (stream)
(with-input-from-string (line-stream (read-line stream))
(read-lists-on-stream line-stream)))
(defun read-lists-on-stream (stream)
(loop for x = (read stream nil 'eof)
until (eql x 'eof)
collect x))
If instead you want to read the whole contents of a file to
its normal eof, you can just use the second function. The
only purpose of the first is to isolate the lists on one line
into a stream of their own.
(Warning: I didn't test the above code. But I've written it so
many times that I'm sure it's at least close to right.)
- - -
Note, too: The eof-val (third argument to read) is always a
source of hassle. I've picked EOF here because you said there'd
be only lists and that's a non-list. Usually, you have to pick
a token that's guaranteed not to be on the stream, and two popular
choices are:
(defvar *eof* (gensym "EOF"))
and later ... (read stream nil *eof*) ... (eql x *eof*) ...
to make sure that you have an object that can't be typed. Or
(defvar *eof* (list nil))
which is less memory overhead but is also a unique cons that
cannot (by nature) be EQL to anything on the stream. Still,
some people find the (list nil) idiom obscure and prefer
(gensym "EOF") just because it's a little more clear about its
intent.