[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] [scheme-reports-wg2] DISCUSSION/VOTE: The character tower



John Cowan <cowan@x> writes:

> 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.

Yes.

> 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.)

Yes.

> 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.

Yes.

> 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.

Yes.

> 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.)

Yes.


Taylan

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports