Browse thread
Strings
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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
modified."
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.
Best,
Daniel