Hi Taylor,

many thanks for the naming suggestions---on many of them, I intend to
do a little poll later, together with suggestions others have made.
Some remarks and questions on the issues where I actually have
opinions:

Taylor Campbell <xxxxxx@bloodandcoffee.net> writes:

> 1. For the input routines, it would simplify things to conjoin the
>    INPUT-BYTES & INPUT-BYTES-N, and likewise with the string input
>    routines and the string & byte port readers, by simply making the
>    count parameter optional to INPUT-BYTES.

I believe Sebastian suggested something similar.  I'm averse to this
because INPUT-BYTES and INPUT-BYTES-N really do different things:
INPUT-BYTES returns whatever is available; INPUT-BYTES-N really tries
to collect a certain number of bytes, and blocks until then.  This becomes
especially apparent when you look in the reference implementation.

I also dislike optional arguments and try to avoid them.  When they
are used, I prefer that their absence denotes default values for the
corresponding parameters (like READ-CHAR and so on), which wouldn't be
the case here.

> 5. It has seemed to be conventional for procedures named CALL-WITH-...
>    to call their last argument with some value, such as a newly opened
>    port, while WITH-... sets up something in the dynamic environment
>    and calls the procedure passed to it with zero arguments.  This is
>    how R5RS's four procedures with these name styles work.  Therefore,
>    I think it would be better to use either WITH-CURRENT-INPUT-PORT or
>    WITH-INPUT-FROM-PORT for what is CALL-WITH-CURRENT-INPUT-PORT in the
>    current draft, and likewise with CALL-WITH-CURRENT-OUTPUT-PORT.

The problem is that this collides with another convention that
reverses the WITH-... names for the macro versions of the various
CALL-WITH-X... procedures.  The distinction between an operation
binding something in the dynamic environment and one passing an
argument is already made by the word "current."

> 6. The names DISPLAY-CHAR &c. are inconsistent with both the symmetry
>    of reading & writing and the terms 'reader' and 'writer' already
>    used in the specification.  It is claimed that the term 'write' as
>    used in names like WRITE-CHAR is inconsistent with the procedure
>    WRITE, but so is READ-CHAR with READ.  The important part, however,
>    is not the way the element is written but the invariance & symmetry
>    between reading & writing of any sort: objects, characters, bytes,
>    &c.  So it's more consistent to have READ & WRITE, READ-CHAR &
>    WRITE-CHAR, READ-STRING/WRITE-STRING, et cetera pairs than to reject
>    the term 'write' because of its use for the S-expression writer.

Just to make sure I understand you: Within the rationale of this SRFI,
you suggest replacing all the DISPLAYs by WRITEs, correct?

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla