On Mon, Oct 29, 2012 at 5:12 PM, Takashi Kato <[email protected]> wrote: > Hi there, > > I have read the discussion of item #315 and would like you to re-consider. > > Firstly, #\null is not only for terminator but also separator. Such as > ${username}.\0.${password} > > Secondly, #\null can't be simply mapped #vu8(0) on UNICODE world. On UTF16 it > will be > #vu8(0 0).
Keep in mind that we are not forbidding the use of #\null in strings. We're simply acknowledging that many implementations have different string strategies, and there may not be a 1:1 mapping between characters and characters allowed in strings. So we try to allow for all of these strategies. Thus, there are a number of implementations which support Unicode characters but not Unicode strings. There are implementations which allow characters as keystrokes (buckey-bits) which also cannot be used in strings. These are bigger concerns than the use of #\null, but the goal of the small language is to describe the lowest common denominator as it exists now. It is still unclear whether the large language, in addition to providing many more libraries, will also include additional requirements (likely documented as cond-expandable features). If this and other portability concerns are important to you you should definitely bring them up. > If the implementation ties closely to C, then it should use bytevector > instead of using string directly. Being tied closely to C is not relevant here. If the format is a binary one (as PKCS#12 is), then you _must_ be using bytevectors anyway, and your example shows this. I don't think that a shortcut hack for something that will be factored out into one place anyway is a compelling argument. -- Alex _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
