On Mon, 2014-05-05 at 20:51 -0400, John Cowan wrote:

> 5) Should R7RS-large implementations be required to provide the characters
> from #\x80 to #\xFF?  (All Schemes in my test suite do so.)

Yes.

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

Yes, with the exception of code points which are not actually mapped to
any character by the Unicode standard.

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

No.

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

Abstention.  If an implementation is serious enough about Unicode
support to keep its strings in a Unicode normalized form, which ought
not be forbidden, then NUL can never appear in any string. If one wants
codepoint array semantics rather than string semantics, then one
probably wanted blobs instead of strings. OTOH, strings with codepoint
array semantics have a long history of use and it's hard to imagine
people abandoning them.  OTGH, strings containing NULs have been a
problem since inception for FFIs to languages that use NUL-terminated
strings.

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

Yes.

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

Yes, with the exception of code points which are not actually mapped to
any character by the unicode standard and code points which have a
canonical decomposition (ie, the standard ought to allow an
implementation to implement strings as unicode normalized strings).

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

No.

> 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.  Identifiers which are distinct when in NFKC/NFKD normalized form
must be considered distinct by all implementations.  Identifiers which
are not distinct when normalized as NFD/NFK must _not_ be considered
distinct by any implementation.  The standard should give a definite
rule about identifiers which are distinct in NFD/NFK normalizations, but
identical in NFKC/NFKD normalizations; are they to be considered
distinct, considered identical, or is that implementation-defined?

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

			Bear

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