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 SAA05533; Mon, 3 Mar 2003 18:12:38 +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 SAA05213 for ; Mon, 3 Mar 2003 18:12:36 +0100 (MET) Received: from grace.speakeasy.org (grace.speakeasy.org [216.254.0.2]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id h23HCYT21647 for ; Mon, 3 Mar 2003 18:12:34 +0100 (MET) Received: (qmail 12955 invoked by uid 36130); 3 Mar 2003 17:12:33 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 3 Mar 2003 17:12:33 -0000 Date: Mon, 3 Mar 2003 09:12:32 -0800 (PST) From: brogoff@speakeasy.net To: Luc Maranget cc: Xavier Leroy , Oliver Bandel , "caml-list@inria.fr" Subject: Re: [Caml-list] Strings as arrays or lists... In-Reply-To: <200303030850.JAA0000025232@beaune.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam: no; 0.00; brogoff:01 caml-list:01 demonstrate:01 char:01 abstraction:01 flamewar:01 haskell:01 unboxed:01 ropes:01 applicative:01 camomile:01 coercions:01 regexps:01 recursion:01 --luc:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Yes, Xavier is right here, and I apologize for posting an "explode" function on this list. I'll appeal for leniency, mentioning that I didn't post "implode", and that I only posted the former function to demonstrate that it could be done, and to point out that one of the many reasons strings as char lists is wrong as a basic type is that you get an abstraction inversion. As far as char lists being somewhat advantageous in a lazy language, well, I won't start a flamewar as to whether laziness as the default is a good design decision (oh hell, I'll admit, I think it isn't) but I'll repeat my observation that in the Clean language, also lazy by default like Haskell, strings are unboxed character arrays. Back to the topic which interests us, OCaml. One thing I'd like to see in an extended library is a fairly rich substring library, perhaps like the one in the SML Basis. I have the beginnings of one, and I also ported the SML one from Moscow ML to OCaml. It can certainly be made richer, the first improvement on my list being an integration with a regexp package. I'm sure there are numerous ideas just for string libraries, and that we could fill an entire mailing list just with those. Ropes (a binary tree representation for applicative "big strings") and extended character sets (I guess Camomile is doing that now?) are my favorites. -- Brian On Mon, 3 Mar 2003, Luc Maranget wrote: > > > > in Haskell, strings are lists of chars. > > > > > > And what a horrible design decision that is! > > > > Agreed. Well, it's a great way to multiply the memory requirements > > for your strings by a factor of 12 (on 32-bit platforms) or 24 (on > > 64-bit platforms), while at the same time losing constant-time > > indexing :-) > > > > Actually, the list representation of strings is so repugnant that I > > don't even want to include "explode" and "implode" coercions between > > string and char list in the standard library. A standard library > > should steer users away from algorithmically-inefficient code. By not > > having implode and explode in the library, I hope OCaml programmers > > will come to the realization that the proper way to operate on strings > > is either via block operations (the String module, regexps, etc), or > > by recursion on integer indices. > > > > - Xavier Leroy > > > > > Xavier is right, of course. > However, in a lazy context, seeing strings as list of chars has some > advantages. This is not relevant to Caml anyway. > > --Luc > > ------------------- > To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr > Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners