Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: brogoff@speakeasy.net
To: Luc Maranget <luc.maranget@inria.fr>
Cc: Xavier Leroy <xavier.leroy@inria.fr>,
	Oliver Bandel <oliver@first.in-berlin.de>,
	"caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Strings as arrays or lists...
Date: Mon, 3 Mar 2003 09:12:32 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.44.0303030851380.11419-100000@grace.speakeasy.net> (raw)
In-Reply-To: <200303030850.JAA0000025232@beaune.inria.fr>

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


  reply	other threads:[~2003-03-03 17:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-27 22:31 Oliver Bandel
2003-02-28  1:03 ` brogoff
2003-03-02 18:34   ` Xavier Leroy
2003-03-02 19:03     ` Alain.Frisch
2003-03-03  8:50     ` Luc Maranget
2003-03-03 17:12       ` brogoff [this message]
2003-03-03 17:40         ` Diego Olivier Fernandez Pons
2003-03-04  2:49     ` Eric C. Cooper
2003-03-04  8:29       ` Fabrice Le Fessant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0303030851380.11419-100000@grace.speakeasy.net \
    --to=brogoff@speakeasy.net \
    --cc=caml-list@inria.fr \
    --cc=luc.maranget@inria.fr \
    --cc=oliver@first.in-berlin.de \
    --cc=xavier.leroy@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox