[plt-scheme] efficient string operations yielding immutable strings

As oppose to where in C for example, which relatively strongly correlates
both it's state and function storage with physical locations, enabling
programmers to both rely on this, as well as being bless and/or cursed with
it's management and designation (in theory to provide them a greater degree
of control over the program's physical storage model for various reasons).

> From: Paul Schlie <schlie at comcast.net>
> Date: Fri, 26 Mar 2004 12:20:40 -0500
> To: <plt-scheme at list.cs.brown.edu>
> Subject: Re: [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-