From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id B1903BB83 for ; Thu, 25 May 2006 09:24:05 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4P7O5dM009563 for ; Thu, 25 May 2006 09:24:05 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA04825 for ; Thu, 25 May 2006 09:24:04 +0200 (MET DST) Received: from mta.conjury.org (grymling.conjury.org [69.12.155.90]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4P7O3sA009558 for ; Thu, 25 May 2006 09:24:04 +0200 Received: from localhost (localhost [127.0.0.1]) by mta.conjury.org (Postfix) with ESMTP id 7084DDAD78 for ; Thu, 25 May 2006 00:24:02 -0700 (PDT) Received: from mta.conjury.org ([127.0.0.1]) by localhost (grymling.conjury.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08619-07 for ; Thu, 25 May 2006 00:23:54 -0700 (PDT) Received: from [69.12.155.94] (spare2.conjury.org [69.12.155.94]) by mta.conjury.org (Postfix) with ESMTP id F1C5BDAD59 for ; Thu, 25 May 2006 00:23:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: References: <20060515141230.ajyupn2z28k0484s@horde.akalin.cx> <446D5E4A.8060005@akalin.cx> <20060519162844.GA32550@osiris.uid0.sk> <200605192226.34917.jon@ffconsultancy.com> <20060520211117.GA2670@first.in-berlin.de> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <77959C0C-D878-412A-A1A3-3C9D382EDB93@conjury.org> Content-Transfer-Encoding: quoted-printable From: j h woodyatt Subject: Re: [Caml-list] Re: immutable strings (Re: Array 4 MB size limit) Date: Thu, 25 May 2006 00:23:51 -0700 To: The Caml Trade X-Mailer: Apple Mail (2.750) X-Virus-Scanned: by amavisd-new at conjury.org X-Miltered: at nez-perce with ID 44755B95.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 44755B93.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; woodyatt:01 jhw:01 mutable:01 trivial:01 runtime:01 mutable:01 variants:01 mutation:01 runtime:01 -unsafe:01 compiler:01 literals:01 arrays:01 woodyatt:01 jhw:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 On May 24, 2006, at 10:56 PM, Martin Jambon wrote: > > So I'd really love to see actual examples where using immutable =20 > strings would be such an improvement over mutable strings. > If the problem is just to ensure that string data won't be changed =20 > by the user of a library, then it is trivial using module =20 > signatures and String.copy for the conversions. I have no dog in this fight, but I can imagine a pragmatic approach =20 that might satisfy some of these concerns without introducing much in =20= the way of extra runtime complexity costs. Change the way strings are boxed so that there is an additional tag =20 for immutable strings as opposed to the normal mutable ones. In all =20 respects, allow string objects with either tag to be treated the same =20= by functions that do not modify the content of the string. When the =20 "safe" variants of the string mutation functions are called on a =20 string object with the immutable tag, throw a runtime exception. =20 Finally, provide a function that changes the tag of a string from =20 mutable to immutable, i.e. like a special blessed case of =20 Obj.set_tag. Not from immutable to mutable, though-- that should be =20 disallowed. If the -unsafe is not set, then allow a new compiler =20 option -constliteral (or something) that would make all string =20 literals immutable. You'd need to use String.copy to get a mutable =20 string with contents copied from an immutable one. Of course, I can't offer a convincing reason to believe this would =20 bring an improvement over what we have today. My proposal would not =20 give the programmer any assurance that contents of string values =20 passed as parameters to library functions are not modified by the =20 library, i.e. the "unsafe" functions would still work. It *might* =20 give a pragmatic benefit of surfacing unintentional programming =20 errors earlier than they might otherwise be found, but I'm not =20 prepared to argue in defense of that. If you did immutable strings this way, it would be nice for the sake =20 of consistency to have a comparable feature for arrays. =97 j h woodyatt