[Ecls-list] About unread-char and bidirectional streams

[Geo Carncross]

On Thu, Jan 1, 2009 at 5:59 AM, Juan Jose Garcia-Ripoll <
juanjose.garciaripoll at googlemail.com> wrote:

> [CC of a message from comp.lang.lisp]
>
> Given the following piece of code, which behavior do you find more
> correct of the ones shown below?
> Is this simply undefined? I found the section on streams in the ANSI
> specification to be, say, lacking in all aspects, hehe.
>
> This is SBCL 1.0.10, an implementation of ANSI Common Lisp.
> "abcdefghijk"
> (0 #\a 1 NIL 0 #\x 1 #\a 2 #\b)
> "abxdefghijk"
>
> ECL (Embeddable Common-Lisp) 8.12.0 (CVS 2008-07-12 18:54)
> "abcdefghijk"
> (0 #\a 1 NIL 1 #\x 2 #\a 2 #\c)
> "axcdefghijk"
>
> Welcome to GNU CLISP 2.45 (2008-04-04) <http://clisp.cons.org/>
> "abcdefghijk"
> (0 #\a 1 NIL 0 #\x 1 #\a 2 #\c)
> "axcdefghijk"
>

CCL agrees with SBCL and Clisp:

"abcdefghijk"
(0 #\a 1 NIL 0 #\x 1 #\a 2 #\c)
"axcdefghijk"

My thinking is that ECL is wrong; Consider a bidirectional stream; what
should write-char do after a unread-char? I think it should clobber the
character read.

I do agree that ECL is currenly complying though; just that the current
behavior is inconvenient. The standard's language on peek-char and
unread-char makes it clear these don't have to interoperate, which indicates
(to me) that nothough should be guaranteed about the file pointer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20090101/0e73d716/attachment.html>