Re: [Caml-list] Feedback on -safe-string migration attempts

[Alain Frisch <alain@frisch.fr>]

On 10/06/2014 04:11 AM, Jacques Garrigue wrote:
> Actually, I think no decision was reached whether the ability to have
> different internal representations for string and bytes is really important.
> This may matter when you use javascript as backend, but otherwise?

I think it's good to keep the freedom to change the representation of 
immutable text.  This could simplify some migration path towards Unicode 
and/or allow using more clever representations (such as ropes, strings 
with lazy concatenation, etc).

Generally speaking, I agree with Gabriel that the distinction between 
strings and bytes is more about "text" vs "compact byte array" data, 
than between immutable vs mutable.  I'm not sure about the need to track 
immutability (or read-only permission) on "byte array", though.  Why 
would this be more important than on other kind of arrays?   In 
particular, for numerical code, it would be equally useful to specify 
immutability of vectors/matrices.  Do we want to go into this direction 
of tracking mutation of arrays?

Actually, I think it would be interesting to introduce a module type 
"ARRAY" for arrays with a fixed type "elt" of elements, add a Make 
functor to the Array module, and arrange so that "Bytes" is a subtype of 
"ARRAY with type elt = char" (in particular, it's "t" type shouldn't be 
more parametric than the one in the ARRAY signature).  We could 
similarly provide a compact "BoolArray" implementation, and if we ever 
decide to drop the automatic runtime unboxing of float arrays, we would 
of course provide a "FloatArray" replacement. "Polymorphic" algorithms 
on arrays could be parametrized by a first-class ARRAY module argument 
(and this would possibly work nicely with modular implicits, and 
possibly with a more aggressive inliner).

This is quite independent from the current discussion, but perhaps it 
shows that we shouldn't treat "Bytes" too specifically compared to other 
kinds of arrays.


Alain