[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] poll: invalid item #315 from 5th ballot

Takashi Kato scripsit:

> I have read the discussion of item #315 and would like you to
> re-consider.

At this stage of the WG1 process, that is extremely unlikely.

> Firstly, #\null is not only for terminator but also separator. Such
> as ${username}.\0.${password}

As was noted earlier, the characters 1C, 1D, 1E, and 1F are already
allocated by ISO for this purpose.

> Secondly, #\null can't be simply mapped #vu8(0) on UNICODE world. On
> UTF16 it will be #vu8(0 0).

True.  However, an implementation based on UTF-16 has no reason to
forbid #\null in strings.  The vote says only that implementations
MAY forbid #\null in strings, not that they MUST do so.  At present,
no Scheme implementation forbids #\null in strings.

> If the implementation ties closely to C, then it should use bytevector
> instead of using string directly.

For purposes such as pathnames, bytevectors are very inconvenient.

> As long as R7RS has bytevector, then string should be able to
> contain #\null otherwise user need to know the length of #\null,
> then string->utf16 procedure cannot simply be provided. (if R7RS has it)

R7RS-small does not have it, although an implementation may provide it,
and it will probably exist in R7RS-large.

An observable characteristic is not necessarily         John Cowan
a functional requirement.  --John Hudson                cowan@x

Scheme-reports mailing list