Taylan Ulrich Bayırlı/Kammer scripsit:

> Make-string and string seem to be specified to return mutable strings.
> (The "newly allocated" part makes that clear I think.)

Even without that, 3.4 is very clear:

        Every object that denotes locations is either mutable or
        immutable. Literal constants, the strings returned by
        symbol->string, and possibly the environment returned
        by scheme-report-environment are immutable objects.
        All objects created by the other procedures listed in this
        report are mutable.

> That being said, I'm with R6RS on that we should move towards immutable
> pairs and strings by default, not have new types for their immutable
> variants.  In that vein, I wouldn't mind an SRFI defining ways to get
> immutable strings that still work with the usual non-mutating string
> operations.  Whether SRFI 130 or another...

It isn't going to allow a portable implementation, then, which is why
I favor the separate mutable and immutable types.

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Winter:  MIT, / Keio, INRIA, / Issue lots of Drafts.
So much more to understand! / Might simplicity return?
                (A "tanka", or extended haiku)