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

[Erik Pearson]

Hi Gary,

Always the voice of reason :)

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.

I admit I have rarely if ever used peek-char.

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.

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.

Just for kicks, compare this to cltl2 which is crystal clear in this regard:

http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node195.html

What peek-char does depends on the peek-type, which defaults to nil.


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.

Erik.




On Fri, Feb 14, 2014 at 2:55 AM, Gary Byers <gb at clozure.com> wrote:

> 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.
>>
>>
>>
>>
>>


-- 
Erik Pearson
Adaptations
;; web form and function
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20140214/dd54d2f4/attachment.htm>