Re: Issues with Unicode

[Sebastian Egner <sebastian.egner@xxxxxxxxxxx>]

Shiro Kawai wrote:
> I don't know how much R6RS committee want to change string API,
> but I really wish R6RS strings be immutable.

The R6RS members have an ambitious agenda already,
so do not get
your hopes too high that STRING will change in a profound
way,
or even at all, for R6RS.

Nevertheless, I also would like to see native Scheme
strings
eventually to become constants, like integers. With
the rise 
of Unicode, where a character is a lot more than up
to 7 holes
in a punch card, the purpose of the primitive facility
Scheme
calls STRING is really vaporizing quickly---I fail
to see the
benefit of STRING over VECTOR of CHAR. At the same
time, the
need for an advanced and convenient string processing
facility
becomes more pressing for all sorts of 'modern' applications,
e.g. web programming.

Jorgen wrote:
> Another quite important aspect of immutable strings
is that one
> can use ropes as the internal representation, effectively giving
> high-performance STRING-APPEND and SUBSTRING operations. From my
> experience (and I guess others'), those are much more common than
> string mutation anyways.

One could start with a SRFI for immutable strings
as an add-on
library---in the hope that the Scheme community will
pick it up
as the primary string type in the distant future.

About a year ago I started working on this in some
fringe time,
but did not complete it to the point where I would
want to go
public with it. One of the things I learned, however,
was that
there are other exciting advanced data structures.
E.g.

        http://portal.acm.org/citation.cfm?id=324139

Describes a deque (double-ended queue) with catenation
with
all operations O(1) worst-case. I wasn't aware that
this is
even possible at all. But before you get too excited:
The
constants hidden in the O(-) are substantial, and
a general
purpose substring operation must be added (although
the obvious
implementation is already O(length of substring),
which the
primitive strings have as well.)

People might argue that the primitive strings of R5RS
are much
more efficient than any advanced string type, e.g.
ropes. This
is true, of course, but at the same time it is not:
by the time
your application does what you want using primitive
strings it
will probably be less efficient for all the cut corners
than a
well designed general library with advanced string
operations.

Sebastian