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