Re: Guile: What's wrong with this?

[Bruce Korb]

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.