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
bear
(14 Jul 2005 00:23 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
bear
(14 Jul 2005 01:52 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