Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Stop at exception
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <xavier.leroy@i...>
Subject: Re: [Caml-list] Non-mutable strings
> I noted in the comments for Ocaml 3.02
> - Removed re-sharing of string literals, causes too many surprises with 
>   in-place string modifications.
> and therefor assumes that if I have a function like
> let foo x =
> 	"This is a string", x ;;
> will foo create a new string each time foo is called?

No, the string is still shared.  What was removed in 3.02 is a
posteriori re-sharing of identical string literals in a compilation
unit.  Consider:

let f () = "foo"
let g () = "foo"

In ocamlopt pre 3.02, we had f() == g().  Now, f() != g().  But we
still have f() == f().

> Assume that I know that no one will in-place edit the string, I could
> rewrite the code into the more efficient
> let str = "This is a string";;
> let foo x =
> 	str, x ;;
> and all calls to foo will get the same string.

No need to do this.

> If so, I wonder why not the standard strings of Ocaml are nonmutable?
> It works fine for languages like Visual Basic, and Visual Basic has
> great string performance compared to languages like C++.

If we were to start again from scratch, I'd consider immutable strings
seriously.  Having mutable strings is handy when they are used as
character buffers, e.g. by low-level I/O functions.  But I agree there
are advantages to distinguish (immutable) strings and (mutable)
character buffers.

- Xavier Leroy
Bug reports:  FAQ:
To unsubscribe, mail  Archives: