This site is a static rendering of the Trac instance that was used by R7RS-WG1 for its work on R7RS-small (PDF), which was ratified in 2013. For more information, see Home.

Ticket 493: Full Unicode support is not portable

2013-07-07 03:20:44
WG1 - Core
alexshinn
major
cowan
wontfix
source
closed
2013-05-12 23:13:59
defect

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.

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.

resolutionwontfix
statusnewclosed

The WG decided by unanimous consent to take no action on this ticket.