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 <lukstafi@gmail.com>wrote:

> On Wed, Mar 14, 2012 at 10:03 PM, Edgar Friendly <thelema314@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.
>