[r6rs-discuss] Strings

From: Shiro Kawai <shiro>
Date: Thu Mar 22 20:04:17 2007

From: MichaelL_at_frogware.com
Subject: Re: [r6rs-discuss] Strings
Date: Thu, 22 Mar 2007 18:30:22 -0400

> I think it's possible to argue that specifying UTF-16 would enhance the
> future survival of code, not diminish it. After all, the meaning of UTF-16
> won't change. So any efficient UTF-16 code you write now would continue to
> work 30 years from now.
[...]
> If you want to write code now that works 30 years from now it's possible
> to argue that you should be more specific, not less. And you shouldn't
> change your mind. (If you want a new kind of string, add a new kind of
> string, don't change the old one.)

I didn't say I want to write a code now that works 30 years later.
What I said is I want to program in Scheme 30 years later.

I expect both application code and underlying implementation
will change a lot in a long term. I don't expect at all that I'll
be using the same string library implementation 30 years later.
I'd rather expect the implementation will be updated frequently,
catching up the latest technology available at that moment.
As far as the API is abstract enough, it will be easy to swap
implementation since it can be independently updated from
application code.

Suppose the language defines that the environment the closure
captures is an assoc-list (of variable names and valuse), and
exposes APIs that takes the environment at arbitrary place of
the code. It's a nice, clean API good to write interactive
debugger on it. Once people widely use code that peeks
and modifies alist environment casually, it would be difficult
to write an optimizing compiler. I'm talking about that kind
of stuff.

We may lock to a certain kind of string representation now and
call it a "string". Later we may find another represetation
more efficient on the platform at the moment and add the new
type of string, "newstring", to the language, then some time
later the innovative hardware came around and we add
"superstring" to the language, .... In lots of areas
backward compatibility is very important, so I understand
there are systems that provides API foo and fooEx and fooEx2
and so on. Actually majority of systems are necessarily to
be so. But we alreay have enough languages in such kind, don't we?

--shiro
Received on Thu Mar 22 2007 - 20:03:40 UTC