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-03 (17:51)
From: Daniel_Bünzli <daniel.buenzli@e...>
Subject: Re: [Caml-list] Strings

Le 3 avr. 09 ŕ 18:52, Martin Jambon a écrit :

> I love this recurrent discussion!

I love your carefully argumented response !

> - I see absolutely no practical advantage of having an immutable  
> "character
> string" type.

In fact I find the result of the following sequence of operations very  
disappointing for a functional programming language :

         Objective Caml version 3.11.0

# Sys.os_type;;
- : string = "Unix"
# let s = Sys.os_type;;
val s : string = "Unix"
# s.[0] <- 'a';;
- : unit = ()
# Sys.os_type;;
- : string = "anix"

I think it is a design error to conflate strings and byte arrays. You  
clearly want both, but each with its own type and strings as  
immutable. Individual character mutability is rarely needed in text  
processing and having immutable strings avoids the kind of quirks as  
seen above.

You'll think that's a marginal example, but that actually happens in  
practice. For example in xmlm when I return a signal for a start tag I  
do not String.copy the tag name to avoid allocating too much. Thus in  
the documentation there's the following ugly advice :

"The module assumes strings are immutable, thus strings the client  
gives or receives during the input and output process must not be  

And if you don't follow the advice and mutate the tag's name before  
the end tag was parsed (or output) you'll get a tag mismatch error  
even though the document (or the output) is perfectly valid.

Having immutable strings would not rely on the client for correctness  
of operation and that's always an advantage. Of course you'll tell me  
just use String.copy inside xmlm et voilŕ, but then you traded  
correctness for performance in a case where you could have both with  
immutable strings.

> - There is nothing to change in OCaml's string type because it is an  
> "array of
> bytes", with type char representing single bytes.

Oh no, there's nothing to change at all, that's a perfect  
implementation of byte arrays. You just want another type for  
immutable strings.