Re: Strings

[Zheng Li <zheng_li@users.sourceforge.net>]

On 4/4/2009 11:10 AM, David Rajchenbach-Teller wrote:
>
> On Fri, 2009-04-03 at 23:44 +0200, Goswin von Brederlow wrote:
>> It wouldn't be too hard to change the string module to allow for both
>> mutable and immutable strings:
>
> [...]
>
> Done in Batteries.
>
> # "foo";;   (*OCaml base string*)
> - : string = "foo"
> # ro"foo";;(*Read-only string*)
> - : [ `Read ] Batteries.String.Cap.t = ro"foo"

With phantom type alone, the abstraction can still leak.

----
# open Batteries.String.Cap;;
# let s = "asdf";;
val s : string = "asdf"
# let ro_s = read_only (of_string s);;
val ro_s : [ `Read ] Batteries.String.Cap.t = ro"asdf"
# s.[3] <- 'z';;
# ro_s;;
- : [ `Read ] Batteries.String.Cap.t = ro"asdz"
----

Well, this example is artificial. A more intuitive example would be 
(Look how similar it is with the previous os_type string example !):

----
# let ro_s = ro"asdf";;
val ro_s : [ `Read ] Batteries.String.Cap.t = ro"asdf"
# (to_string ro_s).[3] <- 'z';;
....
----

however, with no covariants defined in batteries' String.Cap.t type 
(why?), the second example won't compile. The compiler simply doesn't 
allow me to print out a read-only string, nor does it allow many 
reasonable things like <<join ro"asdf" ro"jkl">> etc.

I understand that the phantom trick can't guarantee the immutability in 
a whole since the underlying data type (if exposed) can still be 
mutable. However, String.Cap.t is not dealing with arbitrary polymorphic 
types here! it deals with just the specific primitive string type, and 
controlling capacity over standard string is the only thing it intend to do.

String.copy on the border might solve this problem, even though there 
could still be other issues left.

All the best
--
Zheng