[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/