is the following behavior required by ANSI?
(let ((cs (make-concatenated-stream (make-string-input-stream "a"))))
(unread-char (read-char cs) cs)
(eql (peek-char nil cs)
(peek-char nil (first (concatenated-stream-streams cs)) nil nil)))
==> T
Even if it is not required, do people expect this to hold?
(i.e., that unread-char on a concatenated-stream will push the char
through to the first constituent stream).
LWW & CMUCL return T,
CLISP returns NIL (it keeps the unread char
with the concatenated-stream, not the constituent).
···@gnu.org (Sam Steingold) wrote in message news:<····························@posting.google.com>...
> is the following behavior required by ANSI?
>
> (let ((cs (make-concatenated-stream (make-string-input-stream "a"))))
> (unread-char (read-char cs) cs)
> (eql (peek-char nil cs)
> (peek-char nil (first (concatenated-stream-streams cs)) nil nil)))
> ==> T
>
> Even if it is not required, do people expect this to hold?
> (i.e., that unread-char on a concatenated-stream will push the char
> through to the first constituent stream).
>
> LWW & CMUCL return T,
> CLISP returns NIL (it keeps the unread char
> with the concatenated-stream, not the constituent).
same for other composite streams:
(let ((cs (make-two-way-stream (make-string-input-stream "a")
*standard-output*)))
(unread-char (read-char cs) cs)
(eql (peek-char nil cs)
(peek-char nil (two-way-stream-input-stream cs) nil nil)))
(let ((cs (make-echo-stream (make-string-input-stream "a")
*standard-output*)))
(unread-char (read-char cs) cs)
(eql (peek-char nil cs)
(peek-char nil (echo-stream-input-stream cs) nil nil)))
opinions?
Sam Steingold wrote:
> opinions?
I have never used concatenated streams, but I guess a related question
would be: Are read operations on a concatenated stream also performed on
the underlying streams? The description in the HyperSpec only states
that the sequence of data that can be read is the same as the
concatenation of sequences of data that could be read from the
underlying streams. This doesn't necessarily mean that a read operation
on a concatenated stream "takes" the character "away" from other
contexts that may read directly from the underlying stream.
If read operations are actually performed on the underlying streams I
would expect unread-char also to be performed on the underlying stream.
If not, then not.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
From: Joe Marshall
Subject: Re: unread-char on concatenated streams
Date:
Message-ID: <llh43y7a.fsf@ccs.neu.edu>
···@gnu.org (Sam Steingold) writes:
> is the following behavior required by ANSI?
>
> (let ((cs (make-concatenated-stream (make-string-input-stream "a"))))
> (unread-char (read-char cs) cs)
> (eql (peek-char nil cs)
> (peek-char nil (first (concatenated-stream-streams cs)) nil nil)))
> ==> T
>
> Even if it is not required, do people expect this to hold?
> (i.e., that unread-char on a concatenated-stream will push the char
> through to the first constituent stream).
>
> LWW & CMUCL return T,
> CLISP returns NIL (it keeps the unread char
> with the concatenated-stream, not the constituent).
I don't think I'd expect it to hold. If the character originated on
the nth constituent stream, I could see it going back on to the stream
it came from.
Joe Marshall <···@ccs.neu.edu> writes:
> I don't think I'd expect it to hold. If the character originated on
> the nth constituent stream, I could see it going back on to the stream
> it came from.
concatenated-streams' constituents are discarded as they are no-longer
needed.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)