caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: blue storm <bluestorm.dylc@gmail.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Strings
Date: Sat, 4 Apr 2009 12:55:34 +0200	[thread overview]
Message-ID: <527cf6bc0904040355x32830525h4d191032f34b271f@mail.gmail.com> (raw)
In-Reply-To: <cbe39dfc0904040226k5516a9bcvd57aa3c7b8fe5528@mail.gmail.com>

On Sat, Apr 4, 2009 at 11:26 AM, Alp Mestan <alp@mestan.fr> wrote:
> However, let's study Haskell's strings.
> They simply are a list of characters. This let the ability to use heavily
> list-related functions (take, takeWhile, drop, dropWhile, map, etc.). On the
> other hand, OCaml's standard library lacks of many functions for strings ! I
> think this is too much imperative oriented. Maybe we could try to implement
> (for Batteries or in a separate project) string lists and then use the power
> of Batteries' list module with many (really many... that's a real pleasure
> to read its documentation) functions to work with. I think with a bit of
> internal laziness, we could get a great immutable string type with many
> functions to manipulate it.
>
> But I guess there are many cons to do so, otherwise it would have been
> "standardized".

This is actually a bad idea : strings and lists are used for different
purpose. Some operations are common (takeWhile is probably a good
example) but the concepts are differents (does "tail" as a primitive
on a string really match your usage pattern ?) and using lists entails
bad performance caracteristics (hence the need for byteString, etc.,
the lack of standardization among the different Haskell libraries
using strings, and the general confusion resulting). In the (rare
imho) cases where you exactly want a list of characters, you can use
(string -> char list) (or string -> char Enum.t) conversion functions.

In the immutable string land, we have much better representations
(that is, implementations that match the common use case of strings
better), such as ropes. Ropes provide (amortized ?) constant-time
concatenation, wich I think is the killer feature. I very rarely use
mutable strings, whereas in my experience string concatenation is a
very common operation (more than random access). I expect performance
benefits for most real programs.

In some cases, byte arrays are still useful (as John Harrop noted),
but I think they are anecdotical and I'm ready to explicitely convert
my strings to a mutable format before performing any mutation.


  reply	other threads:[~2009-04-04 10:55 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-03 11:56 Strings Jon Harrop
2009-04-03 12:25 ` [Caml-list] Strings Paolo Donadeo
2009-04-03 14:18 ` Ashish Agarwal
2009-04-03 14:46   ` Jon Harrop
2009-04-03 15:03     ` Daniel Bünzli
2009-04-03 16:52       ` Martin Jambon
2009-04-03 17:50         ` Daniel Bünzli
2009-04-03 19:46           ` Paolo Donadeo
2009-04-03 20:41             ` Harrison, John R
2009-04-04 10:11               ` Jon Harrop
2009-04-04 11:12                 ` David Teller
2009-04-04 11:40                   ` Jon Harrop
2009-04-04 12:34                     ` David Rajchenbach-Teller
2009-04-18 12:31                   ` Arkady Andrukonis
2009-04-04 10:13             ` Jon Harrop
2009-04-03 21:44           ` Goswin von Brederlow
2009-04-04  9:10             ` David Rajchenbach-Teller
2009-04-05 10:06               ` Strings Zheng Li
2009-04-06  9:20                 ` Strings David Rajchenbach-Teller
2009-04-06 10:07                   ` Strings Goswin von Brederlow
2009-04-06 11:03                   ` Strings Zheng Li
2009-04-04 17:11           ` [Caml-list] Strings Kuba Ober
2009-04-04 17:26             ` Jon Harrop
2009-04-05 20:54           ` Richard Jones
2009-04-05 23:40             ` Daniel Bünzli
2009-04-03 18:24         ` Florian Hars
2009-04-03 20:34         ` Arnaud Spiwack
2009-04-04 10:20       ` Jon Harrop
2009-04-04  9:14 ` David Rajchenbach-Teller
2009-04-04  9:26   ` Alp Mestan
2009-04-04 10:55     ` blue storm [this message]
2009-04-04 21:51     ` Goswin von Brederlow
2009-04-04 23:35       ` Yaron Minsky
2009-04-05  9:36         ` David Rajchenbach-Teller
2009-04-05 10:08           ` Alp Mestan
2009-04-05 21:41             ` Goswin von Brederlow
2009-04-05 21:40           ` Goswin von Brederlow
2009-04-05  2:55       ` Jon Harrop
2009-04-05  4:22         ` Edgar Friendly
2009-04-05  7:03           ` Goswin von Brederlow
2009-04-05  6:57         ` Goswin von Brederlow
2009-04-05  7:11           ` Jon Harrop
2009-04-04 10:11   ` Jon Harrop
2009-04-04 21:39   ` Goswin von Brederlow
2009-04-05  7:14   ` Romain Beauxis
2009-04-05  9:34     ` David Rajchenbach-Teller
2009-04-05 21:37     ` Goswin von Brederlow

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=527cf6bc0904040355x32830525h4d191032f34b271f@mail.gmail.com \
    --to=bluestorm.dylc@gmail.com \
    --cc=caml-list@yquem.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;
as well as URLs for NNTP newsgroup(s).