On 01/04/12 04:19, Ian Price wrote:
... As for mutable strings, I consider them a mistake to begin with,...
Let's step back and consider the whole point of Guile in the first place. My understanding is that one primary purpose is to be a facilitation language so that application developers have less to worry about and futz over. An extension language, if you like that phrase. As such, it would seem to me that a primary design goal would be to make the pathway as smooth as possible, rather than trying to emulate C and/or official Scheme language specs as closely as possible. To me, my primary concern is doing my little thing with the least total hassle. Having to study up on and thoroughly understand the Scheme language seems a lot harder than just using Perl (or what-have-you). Most scripting languages don't cut you off at the knees (change interfaces). So my main question is: Which is the higher priority, language purity or ease of use? The answer to that question answers several other things, like whether or not strings should be "allowed" to have high order bits set (not be pure ASCII) and whether or not to make read only strings be copy-on-write vs. fault-on-write.
We could add a compiler option to turn string literals into (string-copy FOO). Perhaps that's the thing to do.
No, because your clients have no control over how Guile gets built. We _do_ have control over startup code, however: (if (defined? 'set-copy-on-write-strings) (set-copy-on-write-strings #t)) Or, better, keep historical behavior and add: (if (defined? 'set-no-copy-on-write-strings) (set-no-copy-on-write-strings #t)) and fix the 1.9 bug (scribbling on shared strings) by making them copy-on-write thingys. Thank you.