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 opinions: 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