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 E853DBB84 for ; Sat, 20 May 2006 20:32:18 +0200 (CEST) Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.3]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4KIWG6h022573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 20 May 2006 20:32:18 +0200 Received: (qmail 1717 invoked from network); 20 May 2006 18:32:15 -0000 Received: from shell2.sea5.speakeasy.net ([69.17.116.3]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 20 May 2006 18:32:15 -0000 Date: Sat, 20 May 2006 11:32:15 -0700 (PDT) From: brogoff To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Array 4 MB size limit In-Reply-To: Message-ID: References: <20060515141230.ajyupn2z28k0484s@horde.akalin.cx> <446D5E4A.8060005@akalin.cx> <20060519162844.GA32550@osiris.uid0.sk> <200605192226.34917.jon@ffconsultancy.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at nez-perce with ID 446F60B0.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; ocaml's:01 arrays:01 arrays:01 mutable:01 overloading:01 wrote:01 wrote:01 caml-list:01 char:01 extensible:01 extensible:01 slower:01 speakeasy:01 monomorphic:01 strings: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.8 required=5.0 tests=SPF_SOFTFAIL autolearn=disabled version=3.0.3 On Fri, 19 May 2006, Brian Hurt wrote: > On Fri, 19 May 2006, Jon Harrop wrote: > > > Agreed. Should OCaml's successor have extensible arrays with 64-bit lengths > > and strings as char arrays? Strings are random access character collections, so under the hood they might be arrays, but I think mutable strings as the default string are a mistake. One can imagine other representations for strings, like ropes. I'd like a language to allow many different underlying string representations. Extensible arrays are useful, but they're slower than fixed sized arrays, so it would be best to provide both. It would be better if there were no special behavior for float arrays. For performance, monomorphic FloatArray or even Float32Array, Float64Array, etc., would be fine with me. And so would the same approach for strings with different character types. It would get mildly annoying without overloading, but maybe that would prompt the language designers to address that issue. > We I designing a language today, I'd have 63-bit array lengths- of course, > I'd do it by not bothering to support 32-bit systems... That would, even today, dramatically reduce the number of potential users of your language. > As for strings, I'd be inclined to make them immutable- I strongly agree with that. > the correct way to manipulate strings is with regular expressions. But definitely not with that. REs have their place in the toolbox though. -- Brian