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
next prev parent 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