On Thu, 10 Feb 2005 17:32:18 -0800 (PST), skaller
<skaller@users.sourceforge.net> wrote:
> Throws out transparency/persistence and fails to
> allow any length changing operations, which are
> common for strings -- overwriting strings is rarely
> needed. The only use I can think of is as a buffer
> (and we have Buffer module for that, and it
> also allows variable length)

As much as I hate to agree with skaller, I do agree here.  :)  Having
the only kind of strings be mutable strings (like this, with each
point in the string being mutable, but not other attributes) is
painful.  I *do* think that having a natively supported type for these
"octet buffers" is handy, especially when doing IO.  But most of the
time, I want something else.

One way to think about why it's irritating for me is that by far the
*easiest* things to point to for "reasons the ML type system is really
helpful" are refs and options.  Because the default behavior is that
everything is immutable, but refs are simple and easy to use, we have
the option in ML to choose whether our datatype should be mutable or
not.  (Extend that somewhat to include Caml's mutable annotation,
which I think is acceptable.)  Likewise, by default every value must
be given, but options give us the ability to provide a kind of "null"
value.  (And if we wish to define our own datatype, we can distinguish
different types of null--N/A vs. unknown, for a basic example.)

But the way Caml strings are done forces us to deal with the fact that
every string is mutable--we don't have the option of making a string
that isn't.  If we want to, we can package things up to prevent
this--providing a way to box up a string into an immutable string
(make a copy, prevent mutation using the type system).  But then we
can't use the standard library without unboxing (making another copy)
to get a "normal" string value out.

This isn't the end of the world, of course.  But it is a wart that I
periodically meditate on.

John.