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

[Alex Shinn <alexshinn@x>]

On Mon, Oct 29, 2012 at 5:12 PM, Takashi Kato <ktakashi@x> 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
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports