John David Stone writes:
The proposed R7RS doesn't require Unicode, so several of the R6RS programs that I've written would have to be extensively revised in order to be portable under the R7RS proposal. I really don't want to have to go back to seven-bit ASCII for strings and symbols.
Here's a typical example: Some of the libraries I've written this semester deal with formulas of the propositional calculus as data. I know from past experience that using the symbols 'and, 'or, and 'not in those data, as conjunction, disjunction, and negation signs, confuses students. So I don't use those symbols; I use the logicians' symbols at codepoints 2227, 2228, and 00AC instead. This saves me from having to think up some misspelling or Esperanto equivalent of "and" just to be able to render the datum without misleading readers.
The WG decided by unanimous consent to take no action on this ticket.
This objection is cogent. However, many programs in the domain of the small language do not require extensive character support, and Unicode support is emphatically not free, especially in the resource-constrained environments that are once more becoming popular. For this reason, non-ASCII characters are not required, and the procedures which require substantial tables to support full Unicode are segregated in an optional library which need not be loaded, even on a full-Unicode implementation, if they are not needed. By leaving full support as a quality-of-implementation issue that can be tested for by cond-expand, we permit greater flexibility to satisfy other implementation requirements such as compactness and speed.