<div dir="ltr">Hi Gary,<div><br></div><div>Always the voice of reason :)</div><div><br></div><div>My question started with a naive use of peek-char while testing at the repl. I just typed in (peek-char stream) and it hung. To my simple mind, the first argument to peek-char would naturally be the stream.</div>
<div><br></div><div>I admit I have rarely if ever used peek-char. </div><div><br></div><div>Then when I looked it up, to my surprise, I discovered the lack of a defined default value for peek-type curious, followed by the mysterious statement I pointed out which defines the behavior of the function with respect to the first two arguments.</div>
<div><br></div><div>I realize there is a contradiction between the normal usage of optional arguments and the interpretation I attributed to that particular passage. I can now interpret that strange phrasing as a roundabout way of stating that the default value for peek-type is nil.</div>
<div><br></div><div>Just for kicks, compare this to cltl2 which is crystal clear in this regard:</div><div><br></div><div><a href="http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node195.html">http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node195.html</a><br>
</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">What peek-char does depends on the peek-type, which defaults to nil. </blockquote>
</div><div><br></div><div>The ccl code validates the peek-type argument, it just does it after the peeking rather than before. Sounds reasonable, just doesn't work well in this case.<br></div><div><br></div><div>Erik.</div>
<div><br></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 14, 2014 at 2:55 AM, Gary Byers <span dir="ltr"><<a href="mailto:gb@clozure.com" target="_blank">gb@clozure.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The case where tne PEEK-TYPE argyment is provided as (or defaults to)<br>
NIL is well-defined, as are the cases where it's provided as T or as<br>
a CHARACTER,  You're apparently trying to decide how the undefined<br>
case where PEEK-TYPE is a stream should behave.<br>
<br>
I don't see anything in the spec that -reqirres- implementations<br>
to treat undefined cases as errors, but if there's something else<br>
that an implementation  could usefully do instaad of signalling an<br>
error CCL's implementation of PEEK-CHAR isn't doing it.<br>
<br>
For all intents and purposes, it is a bug that CCL's PEEK-CHAR<br>
runction doesn't validate its peek-type argument.<br>
<br>
On Thu, 13 Feb 2014, Erik Pearson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm doing some gray streams programming and came across a weird little<br>
corner case. In ccl, when jkI call peek-char with just the gray stream (it is<br>
a string-based stream), ccl hangs. Other lisps (clisp, sbcl) throw an<br>
exception, complaining that the peek-type is not an expected type (one of<br>
the types defined for peek-type - null, t, character)<br>
However, CLHS says:<br>
<br>
If peek-type is not supplied or nil, peek-char returns the next character to<br>
be read from input-stream<br>
</blockquote>
<br>
Note that the case that you're considering is one where the peek-type<br>
argument is supplied as a stream.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="http://clhs.lisp.se/Body/f_peek_c.htm" target="_blank">http://clhs.lisp.se/Body/f_<u></u>peek_c.htm</a><br>
<br>
So ... wouldn't one expect that (peek-char stream) would behave like<br>
(peek-char nil stream)?<br>
<br>
And as a reminder here is what peek-char looks like:<br>
<br>
peek-char &optional peek-type input-stream eof-error-p eof-value recursive-p<br>
=> char<br>
<br>
So there are two issues here. First is how peek-char should behave when a<br>
stream is the first argument. Second is that ccl should probably not hang in<br>
this situation.<br>
<br>
CCL looks to be doing the right thing by using standard input as the default<br>
stream, which it does because it doesn't think a value has been supplied for<br>
the stream argument. It only inspects the first argument after reading from<br>
the stream, which hangs because there is nothing in standard input (in my<br>
case).<br>
<br>
It should probably inspect the first argument first, and if it is an input<br>
stream either reject it like the other lisps (wrong, imo) or use it as the<br>
input stream if it is a input-stream-p (and make necessary adjustments to<br>
the other arguments).<br>
<br>
Thoughts?<br>
<br>
Thanks,<br>
Erik.<br>
<br>
<br>
<br>
<br>
</blockquote>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Erik Pearson<br>Adaptations<br>;; web form and function 
</div></div>