[r6rs-discuss] Strings

From: MichaelL_at_frogware.com <MichaelL>
Date: Thu Mar 22 18:31:00 2007

> 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.

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.

Of course, that's only true if the meaning of "string" doesn't change.
That's just what R6RS is about to do, and it's going to break even the
simplest of code. Look at SRFI-13. "string-reverse" will silently produce
garbage if the string contains combining characters. "string-upcase" won't
produce the same results as R6RS' new "string-upcase". "string-upcase!" no
longer makes sense. "string-set!" is problematic on UTF-8/16
implementations. "string-contains" will become an O(n^2) algorithm on
UTF-8/16 implementations if the "string-ref" issue isn't resolved. (Even
then, some of the suggested resolutions leave "string-ref" O(n) on
UTF-8/16 and introduce new string iterators--so most algorithms using
"string-ref" would still need to be re-written.)

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.)
Received on Thu Mar 22 2007 - 18:30:22 UTC