[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
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports