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        cowan@ccil.org
He played King Lear as though someone had played the ace.
        --Eugene Field

--
You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scheme-reports-wg2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.