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.
Although there is surely a great deal to say about the content of this proposal, I have not yet put enough thought to the matter to articulate it. However, Mike Sperber prompted me to send my initial thoughts on some very minor naming matters to this list, so: 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. 2. A similar simplification could be made on OUTPUT-BYTES and OUTPUT-BYTES-N, &c. 3. END-OF-STREAM?, EOF?, EOF-OBJECT?: It would make more sense to me for EOF? to be renamed END-OF-PORT? to be consistent with END-OF-STREAM?, particularly since some Schemes already have an EOF? that is equivalent to R5RS's EOF-OBJECT?, and EOF? implies that there is a file involved, while there isn't necessarily one with ports. 4. I think it would be better to make the string stream/port names a bit more consistent with each other; to expedite this, here's just my suggestion for the whole set of operations: OPEN-STRING-INPUT-STREAM OPEN-STRING-INPUT-PORT OPEN-STRING-OUTPUT-STREAM OPEN-STRING-OUTPUT-PORT CALL-WITH-STRING-OUTPUT-STREAM CALL-WITH-STRING-OUTPUT-PORT (Similar names would be used for byte vectors as well.) 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. 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.