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

Re: Octet vs Char

This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.



    > From: Shiro Kawai <shiro@xxxxxxxx>

    > From: Ken Dickey <Ken.Dickey@xxxxxxxxxxxxxx>
    > > What am I missing here?

    > I think the issue here is whether we should narrow the
    > possibility of implementation strategies for O(1)
    > ref/set, or allow wider range of implementations (e.g
    > tree, shared substring, multibyte string, etc).

    > Anyway, I'll wait for Tom's new string srfi.


I (purposefully) left the O(1) stuff out of it.  I left out the \U+
syntaxes.  I left out the 256-characters recommendation.  I left out
the ASCII recommendation.  I even left out the "string indexes are
codepoint indexes if the string is made up of codepoints".

I left out everything that was "advice" rather than "requirement" and
left out everything that could be handled in a separate SRFI.  By
startling coincidence (not!), that meant that I left out very nearly
everything that raised any sort of controversy at all in preceding
discussions.

In my opinion, at least at the moment, what's left is necessary and
sufficient for R6RS to adopt to be Unicode-friendly and
extended-character-set-friendly generally.  Everything else can be
additional SRFIs (\U+ syntax, string-index meanings for Unicode
strings) or folklore ("hey, O(1) string-ops are good").

-t