[plt-scheme] efficient string operations yielding immutable strings

Neil,

Out of curiosity, what's your motivation in desiring to specifically
identify objects which are mutable vs. not?

- desire for run-time error/violation detection?

- hints to improve interpreter efficiency, or compiled code?

The reason I ask, is it's not clear to me what the semantic intent of
mutability is within scheme, (beyond "it's easy to imagine..." an
implementation in which some objects value is stored in physically non-
modifiable memory) as to me it seems irrelevant where the originating value
of an object may have been derived from, as scheme appears to out of it's
way not to associate objects with constant physical references, as an
object's physical value storage location can easily be affected by garbage
collection; therefore it's quite "easy to imagine" that the mutation of an
object, who's value may have initially been associated with a physically
non-modifiable storage location, would simply result in a new storage
location and corresponding value being logically associated with that
object.

However if the objective of mutability is to be able to effectively
designate arbitrary object instances (or possibly classes of objects) as
being immutable for some grander semantic purpose, then would observe that
the lack of such a facility to enable it's generalized designation and query
seems conspicuous by it's absents in scheme's specification. (Although it's
true motivation is still not clear to me.)

(but if such a facility was specified, it wouldn't seem that converting a
previously mutable object into an immutable one makes much sense, as opposed
to identifying immutable objects at the time of their definition, which in
turn would itself be inconsistent if it's value were derived from anything
other than statically computable values themselves)?

-paul-