Ok, trivial enough a change. You'll have to make a case for the usefulness of this data structure being in batteries for us to make the change, otherwise, feel free to use the batteries code as a basis for your Tuple data structure. LGPL2.1+linking exception should be sufficiently liberal for most uses.
E. btw, link to the docs I meant to include in my first email: http://ocaml-batteries-team.github.com/batteries-included/hdoc/BatArray.Cap.html On Wed, Mar 14, 2012 at 5:12 PM, Lukasz Stafiniak <lukst...@gmail.com>wrote: > On Wed, Mar 14, 2012 at 10:03 PM, Edgar Friendly <thelema...@gmail.com> > wrote: > > Batteries has a Cap submodule that provides type-level protection for > arrays > > so they can be Read-only/Write-only/Read-write. The same idea with a > > variance annotation and just read-only access seems to be what you're > > looking for, no? > > It seems no, because Cap is invariant, and for a reason: for example, > Hashtbl.Cap.of_table says > "This operation involves no copying. In other words, in let cap = > of_table a in ..., any modification in a will also have effect on cap > and reciprocally." > > What I'm thinking about is type +'a Tuple.t with Tuple.of_list and > Tuple.of_array both performing a copy. > -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
