On Tuesday, 6 May 2014, 2:56, John Cowan <cowan@mercury.ccil.org> wrote:
> 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.
5-7) 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. (it's sometimes convenient if string can have it. For example, AMQP
version negotiation requires "AMQP\x0;\x1;\x0;\x0;", it can be written
in bytevector as well but this is more intuitive.)

> 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.
9-11) Yes. (if characters are supported why not in string? it's clearer
to support the same range.)

> 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. e.g.) people may want to use Japanese character as an identifier.

> 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 (I don't feel strongly yes, but if implementation supports Unicode,
then it's not so difficult to support them.)

Cheers,

_/_/
Takashi Kato
Email: ktakashi@ymail.com

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