English version
Accueil     Ŕ propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis ŕ jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml ŕ l'adresse ocaml.org.

Browse thread
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-04-04 (10:55)
From: blue storm <bluestorm.dylc@g...>
Subject: Re: [Caml-list] Strings
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.