[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Comments on draft 7
-----BEGIN PGP SIGNED MESSAGE-----
On 11/10/2012 02:24 AM, Alex Shinn wrote:
> On Sat, Nov 10, 2012 at 7:21 PM, Takashi Kato <ktakashi@x>
>> 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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Scheme-reports mailing list