Email list hosting service & mailing list manager

constant-time access to variable-width encodings Per Bothner (13 Jul 2005 18:13 UTC)
Re: constant-time access to variable-width encodings Ray Blaak (13 Jul 2005 18:48 UTC)
Re: constant-time access to variable-width encodings Shiro Kawai (13 Jul 2005 20:16 UTC)
Re: constant-time access to variable-width encodings Per Bothner (13 Jul 2005 20:36 UTC)
Re: constant-time access to variable-width encodings Shiro Kawai (13 Jul 2005 23:07 UTC)
Re: constant-time access to variable-width encodings Per Bothner (14 Jul 2005 00:39 UTC)
Re: constant-time access to variable-width encodings Thomas Bushnell BSG (14 Jul 2005 07:18 UTC)
Re: constant-time access to variable-width encodings Thomas Bushnell BSG (14 Jul 2005 07:16 UTC)

Re: constant-time access to variable-width encodings Shiro Kawai 13 Jul 2005 23:07 UTC

>From: Per Bothner <xxxxxx@bothner.com>
Subject: Re: constant-time access to variable-width encodings
Date: Wed, 13 Jul 2005 13:35:59 -0700

> Shiro Kawai wrote:
> >  And this is too much variable-length-character centric
> > API, which fixed-length character implementation or other
> > implementations (such as tree of segments) wouldn't care much.
>
> Not sure your point.  Certainly a more complex data structure is
> appropriate for (say) a text editor, especially once you support
> character "attributes".

What I meant was that, although your proposal works mostly
fine with existing conventions, programmers do need to take
extra care to make sure things work.  For example, suppose
you want to show a list of first N characters of articles;
you can no longer use (substring str 0 N), since N-th index
may fall to #\partial and the behavior of substring is
undefined in that case.  You need an extra boundary check.
Now, requiring extra code in such case may be understood
by those who used to program in multibyte environment, but
it is difficult to convince those who primarily code in
fixed-character-length enviornment.

--shiro