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

Re: strings draft

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.

At Sun, 25 Jan 2004 19:27:58 -0800 (PST), Tom Lord wrote:
> So far as I know, the details I've heard about Bear's are such that I
> would consider it to conform to the guidance.

But it's not.  Binary trees are O(log(n)), period.  Bear's intended use
cases may often involve shallow trees, but that's not to say they always
will be, or that other people won't write applications that fragment the
tree.  You can keep a tree balanced, but you *can't* keep it constantly
shallow.  An algorithm that assumes O(1) access in such cases will
perform poorly.

> I'm not aware enough about the details of Shiro's.  All I'm (sort of)
> aware of is that he's dealing with a EUCJP -- which sounds very
> challenging if you want to wind up with an implementation suitable for
> intensive string processing.   (Unicode is similarly challenging.)

Gauche can be compiled with EUCJP, SJIS or UTF-8 (and extended to others
with minimal effort).  UTF-8 is especially useful these days as the
standard for exchange on the net and is being used in more and more C
libraries, which is especially relevant in the context of this SRFI.
Even without a flat UTF-8 representation, hybrid representations such as
trees of UTF-8 chords are very tempting.

This is not to say we should encourage UTF-8 either, but I think it is
wrong to discourage implementations that use it or binary trees.