> 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.) _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
