Hi,

It appears that Java sidesteps this issue by making string classes final, so that whenever a string object gets modified a new copy of it is generated, giving the appearance of mutable strings, but not really so. It seems Caml is on the right track with immutable strings, we have work-around methods for those occasions where relegating a state change into a confined area is a workable solution. Otherwise the benefit of functional programming would be lost.

kadee

--- On Sat, 4/4/09, David Teller <David.Teller@univ-orleans.fr> wrote:

> From: David Teller <David.Teller@univ-orleans.fr>
> Subject: Re: [Caml-list] Strings
> To: "Jon Harrop" <jon@ffconsultancy.com>
> Cc: caml-list@yquem.inria.fr
> Date: Saturday, April 4, 2009, 7:12 AM
> The bad thing is that, whenever you have to return text in
> an otherwise
> functional program, you need to enter "mutable array
> of bytes" land. You
> can't just assume that the user isn't going to
> modify that string,
> because, they can, possibly by accident, and any invariant
> relying on
> the fact that your strings can't change are going to be
> broken. In
> particular, any StringSet, any StringMap, etc.
> 
> Cheers,
>  David
> 
> On Sat, 2009-04-04 at 11:11 +0100, Jon Harrop wrote:
> > Why? This data structure is a mutable array of bytes
> and should be treated as 
> > such.
> > 
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs