Browse thread
[Caml-list] Stop at exception
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr