Re: [Scheme-reports] Comments on draft 7 Takashi Kato (10 Nov 2012 10:25 UTC)
Re: [Scheme-reports] Comments on draft 7 Alex Shinn (10 Nov 2012 10:28 UTC)
Re: [Scheme-reports] Comments on draft 7 Ray Dillinger (10 Nov 2012 10:56 UTC)

Re: [Scheme-reports] Comments on draft 7 Ray Dillinger 10 Nov 2012 10:51 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/10/2012 02:24 AM, Alex Shinn wrote:
> On Sat, Nov 10, 2012 at 7:21 PM, Takashi Kato <ktakashi@ymail.com>
> wrote:

>> If implementations must support the same range both string and
>> character, it seems much simpler and have more consistency, IMHO.
>> (of course it doesn't matter which range it follows.)

> The inconsistency already existed separately from #\null. It
> existed historically from characters with buckey-bits (i.e.
> keystrokes represented as characters).  It exists now in several
> implementations which support Unicode characters but not Unicode
> strings.

It's an artifact of a representation choice (null-terminated
strings).  Because that representation choice facilitates
call-level interoperation with languages that use null-terminated
strings (specifically C) requiring that implementations fix the
inconsistency is likely to result in the implementors having to
make a choice between conforming with the standard and
invalidating their existing foreign-call interface.

I agree with Takahashi that it is an ugly inconsistency and
not consistent with blandly stating that strings are sequences
of characters.  Ideally, and as the world moves further to
full Unicode acceptance, we should produce a standard that
has strings *be* simply sequences of characters.

But unless we have a consensus among most implementors that
it is time to fix their foreign-call interfaces with
respect to string representation anyway, it is probably not
appropriate to require strings to be able to contain #/null
at this time.

I would say that making a decision, and potentially a
requirement, as to whether a string can contain *any*
character including #/null and any Unicode character, is
an appropriate issue to raise in the the not-yet-started
R8 effort.

				Bear
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQnjHOAAoJEAOzWkqOibfNxiQH/3gjK+LrQY7SnR2E7tYvGJ8r
fxWY8ZrPGuqgdoQmjoTMnMGFPDoDBhEmeRGNzAz5Ipp0v/x9CIh0s2wGuGH2nvh9
C4Gja2fSt9GNxGyVeScKnLNAKNbVWEm1zHhZh79HS39YUyqW4c0zV8XXP/0JuLFy
eWuaTF0c/rqT4Siu60qGf5ZwIUL0DtN2fHVMKpetMMVubySyHKpgFtO4nAphJ1ok
rRfnPaFXEYzm2umnpNc7K53XWGEPCrIlxeESzBnVff8PWM1GJYFmMGSbQeVZSCyq
eUkF+Ziu7U3jL78Qpa35u0b69eJwLT41z2VBi/vmAziNHU4X28KvJFm/r/dVnc4=
=a3pH
-----END PGP SIGNATURE-----

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