[Openmcl-devel] peek-char, interpretation of first argument

[Erik Pearson]

I'm doing some gray streams programming and came across a weird little
corner case. In ccl, when I call peek-char with just the gray stream (it is
a string-based stream), ccl hangs. Other lisps (clisp, sbcl) throw an
exception, complaining that the peek-type is not an expected type (one of
the types defined for peek-type - null, t, character)

However, CLHS says:

If peek-type is not supplied or nil, peek-char returns the next character
to be read from input-stream

http://clhs.lisp.se/Body/f_peek_c.htm

So ... wouldn't one expect that (peek-char stream) would behave like
(peek-char nil stream)?

And as a reminder here is what peek-char looks like:

peek-char &optional peek-type input-stream eof-error-p eof-value
recursive-p => char

So there are two issues here. First is how peek-char should behave when a
stream is the first argument. Second is that ccl should probably not hang
in this situation.

CCL looks to be doing the right thing by using standard input as the
default stream, which it does because it doesn't think a value has been
supplied for the stream argument. It only inspects the first argument after
reading from the stream, which hangs because there is nothing in standard
input (in my case).

It should probably inspect the first argument first, and if it is an input
stream either reject it like the other lisps (wrong, imo) or use it as the
input stream if it is a input-stream-p (and make necessary adjustments to
the other arguments).

Thoughts?

Thanks,
Erik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20140213/72b9979d/attachment.htm>