develooper Front page | perl.perl6.internals | Postings from July 2002

Re: Mutable vs immutable strings

Thread Previous | Thread Next
Clark C . Evans
July 9, 2002 23:44
Re: Mutable vs immutable strings
Message ID:
On Tue, Apr 23, 2002 at 04:13:24PM -0400, Dan Sugalski wrote:
| Should strings in parrot be mutable or immutable? Right now we've a 
| mix, and that's untenable.

Sorry to comment so late.  I think that the choice above
isn't good enough.  You need both strings and buffers.
I say this beacuse there are two fundamental use cases,
where you are passing around a string and if you keep a
reference to it you don't expect it to change on you.
And the other case, is where you are passing around a 
string (buffer) and it can change on you.  Depending on 
the situation either case can be desireable.

My use cases are primarly immutable, while a few people
are vocal about mutable strings.  Mutable strings aren't
necessarly more-useful; in many cases you need to keep a 
string handle around (say a hashtable key) and know that
it won't be changed on you.  If you are using mutable 
strings, this means you have to store a copy of the string
in this situation.  Storing a string copy has two 
dis-advantages:  first, it means alot of unnecessary
duplication, second, it prevents strings to be compared by
pointer when they are "interned".   Admittedly, you can
layer this on top with application semantics; but this is
less than ideal as it is a source of bugs.

So, I propose that Parrot supports both of these attitudes
of reasoning by using a flag.   Initially, all strings
are 'mutable'.  However, they have a 'freeze' operation which
turns it into a constant; calling freeze on a constant is
a noop.   Obviously, there shouldn't be a thaw function
and calling a mutator operation on a constant string 
should raise an error.

In this way, application semantics can be enforced uniformly
across library and programming language boundaries.  If a 
function asks for a constant string (to keep a copy) then
it can call "freeze" on it before it stuffs it away.  Then,
if some other function tries to change it... the appropriate
error condition occurs.   This is clean and flexible.

That said, one may want to extend this to other types
of objects in a more generic manner.  Python has both
tuples and lists.  A tuple is essentially a constant
list.   Constants are needed for mapping keys, when
used as a key, the mapping could 'freeze' the object.
Calling 'freeze' on a composite (such as a list or map)
would recursively freeze all components of the object
and their relation to each other.  Something like this 
would make dictionaries very useable... and would allow
for very clean representation of python's list/tuple, 
buffer/string distinctions.


Yo!  Check out YAML!
YAML is Serialization for the Masses

Clark C. Evans                   Axista, Inc.            800.926.5525
XCOLLA Collaborative Project Management Software

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About