[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] [scheme-reports-wg2] DISCUSSION/VOTE: The character tower
- To: scheme-reports-wg2@x
- Subject: Re: [Scheme-reports] [scheme-reports-wg2] DISCUSSION/VOTE: The character tower
- From: Taylan Ulrich Bayirli/Kammer <taylanbayirli@x>
- Date: Wed, 07 May 2014 17:20:39 +0200
- Cc: scheme-reports@x
- In-reply-to: <20140506005154.GF5011@mercury.ccil.org> (John Cowan's message of "Mon, 5 May 2014 20:51:54 -0400")
- References: <20140506005154.GF5011@mercury.ccil.org>
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