From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=5.0 tests=AWL,DNS_FROM_RFC_POST, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 26319BBC4 for ; Fri, 3 Apr 2009 19:51:48 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwDAGPp1UnRVdykkGdsb2JhbACVZD8BAQEBCQkMBxEDqGWQJQEDAQOEDAaGCg X-IronPort-AV: E=Sophos;i="4.39,320,1235948400"; d="scan'208";a="25591549" Received: from mail-fx0-f164.google.com ([209.85.220.164]) by mail3-smtp-sop.national.inria.fr with ESMTP; 03 Apr 2009 19:51:47 +0200 Received: by fxm8 with SMTP id 8so1234448fxm.27 for ; Fri, 03 Apr 2009 10:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=MUthaxvXVKE2VR1hc40wqeS3LLTBUdEhPnmieQklkKQ=; b=NOQDsoiV3yzWaK22NiY1wBgF2ICfiDa1rhd26PfZ2VU4FbmU01BUmerdSsWtaV+hIf hS+J4ffZyMxFKdmrwWcrv8XHDyDdU/cTZbuw8Eu6RKXTbdB7w2lUvNhi2hPEFCVqP+yu q4mBYRr5l3Txq7xZAo/N80pT+NM6W0nR3Bw0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=PSSu7ueUJ31P++MzxIBTDXhqoCbDWzYQeO9OfIG84a64rKzJrYmUz31dOEbL0539d4 kFqscSWZyrFVnNbMX9zHaMclhcX0vTx0Hm7Z19NCHHDZcb2NbRKTf2UyGH/qfRBNCSTY 1sfP/Y34VClkGhi5Yfl5pitWnpMd2cDriO3jk= Received: by 10.86.87.5 with SMTP id k5mr1225277fgb.45.1238781106862; Fri, 03 Apr 2009 10:51:46 -0700 (PDT) Received: from ?192.168.1.34? (11-195.76-83.cust.bluewin.ch [83.76.195.11]) by mx.google.com with ESMTPS id l12sm4119806fgb.6.2009.04.03.10.51.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Apr 2009 10:51:46 -0700 (PDT) Sender: =?UTF-8?Q?Daniel_B=C3=BCnzli?= Message-Id: <8697F924-0485-4E00-81DF-9BCF74D872EA@erratique.ch> From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= To: OCaml List In-Reply-To: <49D63EE6.2020407@ens-lyon.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: [Caml-list] Strings Date: Fri, 3 Apr 2009 19:50:48 +0200 References: <200904031256.33357.jon@ffconsultancy.com> <200904031546.14071.jon@ffconsultancy.com> <49D63EE6.2020407@ens-lyon.org> X-Mailer: Apple Mail (2.930.3) X-Spam: no; 0.00; bunzli:01 buenzli:01 val:01 byte:01 arrays:01 quirks:01 allocating:01 mismatch:01 ocaml's:01 byte:01 arrays:01 traded:98 char:01 parsed:01 unix:01 Le 3 avr. 09 =E0 18:52, Martin Jambon a =E9crit : > I love this recurrent discussion! I love your carefully argumented response ! > - I see absolutely no practical advantage of having an immutable =20 > "character > string" type. In fact I find the result of the following sequence of operations very =20= disappointing for a functional programming language : Objective Caml version 3.11.0 # Sys.os_type;; - : string =3D "Unix" # let s =3D Sys.os_type;; val s : string =3D "Unix" # s.[0] <- 'a';; - : unit =3D () # Sys.os_type;; - : string =3D "anix" I think it is a design error to conflate strings and byte arrays. You =20= clearly want both, but each with its own type and strings as =20 immutable. Individual character mutability is rarely needed in text =20 processing and having immutable strings avoids the kind of quirks as =20 seen above. You'll think that's a marginal example, but that actually happens in =20 practice. For example in xmlm when I return a signal for a start tag I =20= do not String.copy the tag name to avoid allocating too much. Thus in =20= the documentation there's the following ugly advice : "The module assumes strings are immutable, thus strings the client =20 gives or receives during the input and output process must not be =20 modified." And if you don't follow the advice and mutate the tag's name before =20 the end tag was parsed (or output) you'll get a tag mismatch error =20 even though the document (or the output) is perfectly valid. Having immutable strings would not rely on the client for correctness =20= of operation and that's always an advantage. Of course you'll tell me =20= just use String.copy inside xmlm et voil=E0, but then you traded =20 correctness for performance in a case where you could have both with =20 immutable strings. > - There is nothing to change in OCaml's string type because it is an =20= > "array of > bytes", with type char representing single bytes. Oh no, there's nothing to change at all, that's a perfect =20 implementation of byte arrays. You just want another type for =20 immutable strings. Best, Daniel