A couple of comments about this draft: - The specification refers to a literal `=` several times where the value of the `key-value-sep` is meant. Analogous for `;`. - What happens when the `key-value-sep` or the `comment-delim` are whitespace, especially a newline? - Is whitespace the whitespace from the lexical syntax of R6RS and/or R7RS? - What happens if one of the strings fed to the accumulator contains whitespace or any other special characters? - The generator really should raise a well-defined exception (that would derived from &error in the case of R6RS) if the INI file format is not of the specified format. Only this way, one can be sure that the provided textual data is interpreted correctly. Silent extensions by implementations must not be permitted (at least not without setting a special flag). - The keys and section names really should be represented by symbols, not strings. Symbols are interned, can be compared quickly and have a fast hash function. All this is quite advantageous in the case of INI files. - The strings returned by the generator should probably be immutable ones, in general. - Should the accumulator be allowed to cache results so that the writing may be deferred until it receives an eof object? Should the generator be allowed to read ahead? - By symmetry, the accumulator really should not close the port when receiving an eof object. It should just be error to feed anything but an eof object into the accumulator afterwards. (BTW, `write` also does not close a port when it receives an eof object.)
Marc Am Mo., 26. Sept. 2022 um 22:09 Uhr schrieb Arthur A. Gleckler < [email protected]>: > On Mon, Sep 26, 2022 at 11:58 AM John Cowan <[email protected]> wrote: > >> OK, thanks. Well, let's start the 1-week period on October 3 and then we >> can finalize, as I said, on or about October 10. But go ahead and publish >> the draft as soon as you can. >> >>> > Done. I've made a note to announce a last-call period on 3 Oct, *ceteris > paribus*. >
