Scheme's had a numeric tower for a long time, but R7RS-small also has a character tower. I'm going to put forth a ballot asking people to discuss and vote on what parts of the Unicode character space R7RS-large will require an implementation to have.
Voting runs from now until noon on 2014-05-21, Universal Time, or two weeks plus a tilly. Remember that abstaining has no effect on the outcome, as a majority of legal votes cast decides any question. R7RS-small requires the characters from #\x0 to #\x7F, the ASCII repertoire, to exist. It also requires that characters in the range #\x0 to #\x10FFFF, if they exist, correspond to Unicode characters. 5) Should R7RS-large implementations be required to provide the characters from #\x80 to #\xFF? (All Schemes in my test suite do so.) 6) Should R7RS-large implementations be required to provide the characters from #\x100 to #\xFFFF, excluding the surrogate code points from #\xD800 to \#xD8FF, which do not correspond to Unicode scalar values? (JVM and CLR implementations other than Kawa do this.) Voting yes on this question implies a yes vote on #5. 7) Should R7RS-large implementations be required to provide the characters from #\x10000 to #\x10FFFF? (R6RS implementations and many R5RS and R7RS implementations do this. See <http://trac.sacrideo.us/wg/wiki/UnicodeSupport> for details on particular implementations.) Voting yes on this question implies a yes vote on #5 and #6. 8) Should R7RS-large implementations be required to allow #\x0 in strings? (There have been implementations in the past which did not, for the sake of simpler interchange with C, but none of the test-suite implementations have this restriction.) 9) Should R7RS-large implementations be required to allow the characters from #\x80 to #\xFF in strings? (All implementations in the test suite do so.) 10) Should R7RS-large implementations be required to allow the characters from #\x100 to #\xFFFF in strings? (MIT and RScheme do not, even though they support them as character objects.) Voting yes on this question implies a yes vote on #9. 11) Should R7RS-large implementations be required to allow the characters from #\x10000 to #\x10FFFF in strings? (Again, MIT does not, even though it supports them as character objects.) Voting yes on this question implies a yes vote on #10. 12) Should R7RS-large implementations be required to support identifiers with non-ASCII characters as specified in Section 7.1.1 of R7RS-large? (Most implementations do, either deliberately or because they support almost everything as an identifier.) This permits the use of most languages as a source of Scheme identifiers. 13) Should R7RS-large implementations be required to provide the (scheme char) library, which is optional in R7RS-small? It contains the procedures which require O(n)-sized tables, where n is the number of supported characters in the implementation, namely: char-alphabetic?, char-lower-case?, char-upper-case?, char-whitespace?, char-numeric?; char- and string-upcase, -downcase, and -foldcase; and the char-ci and string-ci procedures. (Essentially all implementations do so, as all of these are required in R6RS and all but the foldcase procedure are required in R5RS. The library was made optional in R7RS-small in order to support embedded implementations that wanted to provide the full range of characters but could not afford the space for tables.) -- John Cowan http://www.ccil.org/~cowan [email protected] He played King Lear as though someone had played the ace. --Eugene Field _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
