[Openmcl-devel] peek-char, interpretation of first argumenthttp://www.nbcolympics.com/video?ocid=Yahoo

[Gary Byers]

The case where tne PEEK-TYPE argyment is provided as (or defaults to)
NIL is well-defined, as are the cases where it's provided as T or as
a CHARACTER,  You're apparently trying to decide how the undefined
case where PEEK-TYPE is a stream should behave.

I don't see anything in the spec that -reqirres- implementations
to treat undefined cases as errors, but if there's something else
that an implementation  could usefully do instaad of signalling an
error CCL's implementation of PEEK-CHAR isn't doing it.

For all intents and purposes, it is a bug that CCL's PEEK-CHAR
runction doesn't validate its peek-type argument.

On Thu, 13 Feb 2014, Erik Pearson wrote:

> I'm doing some gray streams programming and came across a weird little
> corner case. In ccl, when jkI 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

Note that the case that you're considering is one where the peek-type
argument is supplied as a 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.
> 
> 
> 
>