[r6rs-discuss] Strings

From: Shiro Kawai <shiro>
Date: Thu Mar 22 01:52:06 2007

From: MichaelL_at_frogware.com
Subject: Re: [r6rs-discuss] Strings
Date: Wed, 21 Mar 2007 18:13:00 -0400

> Jason Orendorff wrote:
> > The other solution is to standardize the implementation, so that the
> > efficient algorithms don't differ. I want to push this seriously one
> > last time: Unicode strings have been kicked around for a while now,
> > and despite Will's link, real-world implementations do not vary much.
> > I don't think it's premature to standardize.
>
> I started looking into these issues a while ago when we were faced with
> internationalizing an app. (The app runs on several platforms and under
> several web servers.) Before learning about what's out there I would have
> wanted to keep my options open; knowing what I know now I'd agree with
> Jason. It would make sense to standardize on UTF-16 strings and UTF-32
> characters. (Note, btw, that that doesn't preclude UTF-8 strings. It just
> means that the built-in string type would be UTF-16.)

I like to see Scheme being used for very long time, say,
30 years from now. We'll see big changes on hardware and
possibly some new approaches in software, but I expect
the fundamental idea remains same, and I'd like to code
in some descendant of Scheme.

And it is likely that we'll be using some descendant of
Unicode, at least for data exchange; there may be some
innovative approaches for text repersentation, but for
data exchange, standards tend to stick.

However, I feel that current state of wide acceptance of
UTF-16 is more transient. It's used just because it is a
good balance on current hardware and software. If we have
1000x memory, storage, and bandwidth, we may just forget
surrogates complexity and use utf-32 everywhere. Or, even
that "flat array of characters" model will become obsolete.

So, although I think it is important not to exclude widely
accepted practice, we shouldn't lock ourselves to something
that happens to be popular at this moment.

--shiro
Received on Thu Mar 22 2007 - 01:51:35 UTC

This archive was generated by hypermail 2.3.0 : Wed Oct 23 2024 - 09:15:01 UTC