another change for R4RS; peek-char

[William Clinger <will@fog.cs.uoregon.edu>]

To my great surprise, no one has objected since Jonathan Rees
urged the following change, so I have added the following to my
list of changes planned for the R4RS:

Sections 3.2 (True and false), 4.1.5 (Conditionals),
and 6.1 (Booleans).  It will be explicitly unspecified whether
the empty list counts as true or as false in a conditional
expression.

----------------------------------------------------------------

Here is my summary of discussion so far on two of the changes
expected for the R4RS.

Several people have argued against peek-char, but I do not see
any merit whatsoever in their arguments and I intend to ignore
them.  Those of you who have argued against peek-char may want
to try again, but I am inclined to think that you have not read
the following note in the R3.95RS:

     Note: The value returned by a call to peek-char is the same as
     the value that would have been returned by a call to read-char
     with the same port.  The only difference is that the very next
     call to read-char or peek-char on that port will return the
     value returned by the preceding call to peek-char.  In
     particular, a call to peek-char on an interactive port will
     hang waiting for input whenever a call to read-char would have
     hung.

In light of this note, I do not see why peek-char presents any
difficulties that are not already presented by read-char.  In
particular, I do not see any connection whatsoever between
peek-char and char-ready?, so arguments based upon an alleged
connection between the two will be rejected out of hand unless
they explain the connection.

One person has objected, strongly, to making list-ref and list-tail
essential.  Does anyone wish to counter by explaining just why it
is essential that these procedures be essential?

Peace, Will