[plt-scheme] efficient string operations yielding immutable strings

But would still wish a violation like this didn't rely on execution, but
relied on static analysis, (as although desirable, it's often practically
impossible to guarantee 100% observable code coverage prior to deployment).

> From: Paul Schlie <schlie at comcast.net>
> Date: Fri, 26 Mar 2004 13:19:18 -0500
> To: <plt-scheme at list.cs.brown.edu>
> Subject: Re: [plt-scheme] efficient string operations yielding immutable
> strings
> 
> Which makes sense, and would then observe that the generalization of such
> a facility to designate and query not only an object mutability, but also
> a function's mutability attribute, may go a long way in also addressing
> Anton's previously expressed concerns associated with enabling the programmer
> to express their intent that a function not contain or mutate persistent or
> shared state, to aid in their designation, and diagnosis of violation of
> stated intent; rather than try to argue for the preservation
> of scheme's presently ambiguous evaluation order evaluation?
> 
> In fact, wonder if even your intent may be better served by being able to
> specify that a function is immutable, rather than attempting to classify it's
> arguments as being so within the body of the function? (but realize that
> you're working with what you've got, although it's not officially portable
> across arbitrary conforming implementations).
> 
> -paul-
> 
>> From: "Neil W. Van Dyke" <neil at neilvandyke.org>
>> Date: Fri, 26 Mar 2004 12:35:22 -0500
>> To: Paul Schlie <schlie at comcast.net>
>> Cc: <plt-scheme at list.cs.brown.edu>
>> Subject: Re: [plt-scheme] efficient string operations yielding immutable
>> strings
>> 
>> Paul Schlie <schlie at comcast.net> writes at 12:20 26-Mar-2004 -0500:
>>> 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?
>> 
>> Yes, that.
>> 
>> I'm rewriting one of my libraries to use pure-functional objects, since
>> accidental mutation (and burdening the library user with having to
>> decide when to copy vs. mutate) made the old library hard to use safely
>> in nontrivial programs.
>> 
>> Using immutable strings in the implementation is helping to make an
>> efficient implementation that enforces immutability of the objects.
>> 
>> -- 
>>                                            http://www.neilvandyke.org/