[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some comments on minor naming matters

This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.

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

Taylor Campbell <campbell@xxxxxxxxxxxxxxxxxx> 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
>    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