From: Raymond Toy
Subject: peek-char and eof-error-p
Date: 
Message-ID: <4n66raexfu.fsf@rtp.ericsson.se>
In CLHS, the desription for peek-char says:

	If an end of file[2] occurs and eof-error-p is false,
	eof-value is returned.  

However, it also says

	If recursive-p is true and an end of file[2] occurs, an error
	of type end-of-file is signaled.

So what is exactly supposed to happen when I do

(peek-char nil stream nil 'eof t)

where eof-error-p is NIL and recursive-p is T and there is nothing
left on the stream to read?

This shows up in f2cl where CMUCL causes an end-of-file error, but
CLISP apparently does not.

Ray

From: Pekka P. Pirinen
Subject: Re: peek-char and eof-error-p
Date: 
Message-ID: <ix1z1yn6i0.fsf@harlequin.co.uk>
Raymond Toy <···@rtp.ericsson.se> writes:
> In CLHS, the desription for peek-char says:
> 
> 	If an end of file[2] occurs and eof-error-p is false,
> 	eof-value is returned.  
> 
> However, it also says
> 
> 	If recursive-p is true and an end of file[2] occurs, an error
> 	of type end-of-file is signaled.

It is hard to understand why this paragraph would have been included,
if it wasn't meant to override the sentences about eof-error-p (which
are needed to specify its own basic meaning).  However, it doesn't say
so, and the whole Exceptional Situations section of PEEK-CHAR is
clearly hastily edited.

Moveover, RECURSIVE-P causing an error to be signalled conflicts with
the general description of recursive-p in section 23.1.3.  In CLtL2,
this description clearly applied to PEEK-CHAR; in the standard, it
does not as it's now in a different chapter.  That still leaves
PEEK-CHAR as the only function that contains this language about
RECURSIVE-P, as READ-CHAR doesn't.  I can't locate any X3J13 issue
that would have added it, but perhaps somebody can remember why it was
added.

> So what is exactly supposed to happen when I do
> 
> (peek-char nil stream nil 'eof t)
> 
> where eof-error-p is NIL and recursive-p is T and there is nothing
> left on the stream to read?

I think it should not signal an error.  FWIW, LispWorks doesn't.
-- 
Pekka P. Pirinen, Adaptive Memory Management Group, Harlequin Limited
The Lottery is a tax on those who don't believe in math.
From: Erik Naggum
Subject: Re: peek-char and eof-error-p
Date: 
Message-ID: <3170082788395743@naggum.no>
* Raymond Toy <···@rtp.ericsson.se>
| So what is exactly supposed to happen when I do ...  where
| eof-error-p is NIL and recursive-p is T and there is nothing left on
| the stream to read?

  See section 23.1.3 in CLtS.

#:Erik
-- 
  If this is not what you expected, please alter your expectations.
From: Raymond Toy
Subject: Re: peek-char and eof-error-p
Date: 
Message-ID: <4nem5yd9aj.fsf@rtp.ericsson.se>
>>>>> "Erik" == Erik Naggum <····@naggum.no> writes:

    Erik> * Raymond Toy <···@rtp.ericsson.se>
    Erik> | So what is exactly supposed to happen when I do ...  where
    Erik> | eof-error-p is NIL and recursive-p is T and there is nothing left on
    Erik> | the stream to read?

    Erik>   See section 23.1.3 in CLtS.

Thanks for the tip.  My reading of this section says it should not signal
an error because 23.1.3.1 says 

	If it [eof-error-p] is false, then no error is signaled, and
	instead the function returns eof-value.

Section 23.1.3.2, item 3 only talks about the case when eof-error-p is
non-nil.

So, I guess the description of peek-char isn't quite right, and CMUCL
is doing the wrong thing.

Thanks,

Ray