John Cowan <cowan@mercury.ccil.org>:
> 5) Should R7RS-large implementations be required to provide the characters
> from #\x80 to #\xFF?

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?

Yes.

> 7) Should R7RS-large implementations be required to
> provide the characters from #\x10000 to #\x10FFFF?

Yes.

> 8) Should R7RS-large implementations be required to allow #\x0 in strings?

No.  I would even suggest the text to *require* one not to allow nulls, and
instead use homogeneous string-vectors when one needs them.

It has ramifications for FFI ("why did the procedure foobar not see all my
characters? Oh, because of the #\x0 in there."), and many implementations
rely on C functions.

Someone may convince me otherwise. I know that Python allows it, for instance,
and it may have its merits, but I can't see any contra a string-blob.

> 9) Should R7RS-large implementations be required to allow the characters
> from #\x80 to #\xFF in strings?

Yes.

> 10) Should R7RS-large implementations be required to allow the characters
> from #\x100 to #\xFFFF in strings?

Yes.

> 11) Should R7RS-large implementations be required to allow the characters
> from #\x10000 to #\x10FFFF in strings?

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?

Yes.

> 13) Should R7RS-large implementations be required to provide the
> (scheme char) library, which is optional in R7RS-small?

Yes.

--
Christian Stigen Larsen

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