From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA21201; Thu, 10 Jan 2002 18:56:22 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA19544 for ; Thu, 10 Jan 2002 18:56:21 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g0AHuJb11791; Thu, 10 Jan 2002 18:56:19 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA20793; Thu, 10 Jan 2002 18:56:19 +0100 (MET) Date: Thu, 10 Jan 2002 18:56:19 +0100 From: Xavier Leroy To: Mattias Waldau Cc: caml-list@inria.fr Subject: Re: [Caml-list] Non-mutable strings Message-ID: <20020110185619.A20606@pauillac.inria.fr> References: <20020104144617.G941@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from mattias.waldau@abc.se on Sat, Jan 05, 2002 at 12:19:45PM +0100 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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