This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.
First, a small typo: 6. These MUST recurse within lists and vectors, so any list or vector in a position that accepts a neoteric expression MUST accept a sequence of zero or more neoteric expressions, not just s-expressions. (Note that this occurs if they are directly or directly within a curly-infix list or a neoteric-expression.) [...] ^^^^^^^^ Presumably that should be "directly or indirectly", not "directly or directly". An implementation of this SRFI MUST accept the marker #!curly-infix followed by a whitespace character in its standard datum readers (e.g., read and, if applicable, the default implementation REPL). This marker (including the trailing whitespace character) MUST be consumed and considered whitespace. After reading this marker, the reader MUST accept curly-infix expressions in subsequent datums until it reaches an end-of-file or some other conflicting marker (no conflicting marker is specified here). I'd prefer to change the language "[...] in subsequent datums until it reaches an end-of-file [...]" to something closer to "[...] in subsequent datums read from the same port [...]". This is based on the text in section 2.1 of R7RS (draft 6) that describes #!fold-case and #!no-fold-case: #!fold-case #!no-fold-case These directives may appear anywhere comments are per- mitted (see section 2.2) and are treated as comments, except that they affect the reading of subsequent data. The #!fold-case directive causes the read procedure to case-fold (as if by string-foldcase; see section 6.7) each identifier and character name subsequently read from the same port. (It has no effect on character literals.) The #!no-fold-case directive causes the read procedure to return to the default, non-folding behavior. There is a functional difference between the two formulations when reading from a terminal. On POSIX systems, a terminal device will return EOF when CTRL-D is pressed, but then subsequent reads may continue to read more data. This raises the question of whether the #!curly-infix read option should be reset to the Scheme implementation default when CTRL-D is pressed at a terminal. I interpret the current language to mean that the flag should be reset, but I would prefer that the flag retains its setting as long as the port exists. Following the R7RS language also simplifies the handling of reader directives by giving them uniform behavior, and also makes it crystal clear that the flag should be set on a per-port basis (as opposed to a global flag for the process or thread). What do you think? Regards, Mark