[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some comments on minor naming matters
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
> 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