From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2ELR15U024724 for ; Wed, 14 Mar 2012 22:27:01 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqkBANEMYU/RVde2kGdsb2JhbABDhTqfSZEiCCIBAQEBCQkNBxQEI4IJAQEBAwESAg8dARsdAQMBCwYFBAcDCioCAiEBAREBBQEcBhMih2MFC5xwCotETIJxhTc/iHQBBQuJP4YfgRYElVaLLoMbPYQkgUA X-IronPort-AV: E=Sophos;i="4.73,586,1325458800"; d="scan'208";a="136110919" Received: from mail-ey0-f182.google.com ([209.85.215.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 14 Mar 2012 22:26:31 +0100 Received: by eaaf13 with SMTP id f13so1862260eaa.27 for ; Wed, 14 Mar 2012 14:26:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PFNXUwEZdVAimAqq5EoMw8wIsfCAyRlkFCUv60yOOSw=; b=FoY0MxcsUDZD3Pzu1WABNh4C0SGtI++eqRVAj6gqgtsMYB52h5O+HDJj1YVWlCtlKi mWCPQOqs6CqGy0qYaz8k4imRxlWcSkPEFvdSz3/kMi4p+Lz/FpIJgPg179u9jYACkR+G 3dRISLCrGo7ulALbx49kQ1oLCUS5YbTQ2IE9xZERirDXs8PEutYwOZWlKZeKNpx/I1oq S27NB/zE1X7K60P7SGIDP5Fam9qDYgJD+Wy3zdtesetlKdnDKd1gsQs8/qFoHuLT861/ lYsjHaTMgqtfPDSaSdaqp0gBe9aqtzc7L5flVti0X9PqnRfE3mRYE6o3shaavLq5Ac1o ymfQ== MIME-Version: 1.0 Received: by 10.14.99.6 with SMTP id w6mr628048eef.68.1331760391290; Wed, 14 Mar 2012 14:26:31 -0700 (PDT) Received: by 10.213.20.8 with HTTP; Wed, 14 Mar 2012 14:26:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Mar 2012 17:26:31 -0400 Message-ID: From: Edgar Friendly To: Lukasz Stafiniak Cc: Caml Content-Type: multipart/alternative; boundary=bcaec52be4730c803c04bb3aa153 Subject: Re: [Caml-list] Tuples (covariant immutable arrays) --bcaec52be4730c803c04bb3aa153 Content-Type: text/plain; charset=UTF-8 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 wrote: > On Wed, Mar 14, 2012 at 10:03 PM, Edgar Friendly > 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. > --bcaec52be4730c803c04bb3aa153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ok, trivial enough a change.=C2=A0 You'll have to make a case for the u= sefulness of this data structure being in batteries for us to make the chan= ge, otherwise, feel free to use the batteries code as a basis for your Tupl= e data structure.=C2=A0 LGPL2.1+linking exception should be sufficiently li= beral for most uses.

E.

btw, link to the docs I meant to include in my first email: <= a href=3D"http://ocaml-batteries-team.github.com/batteries-included/hdoc/Ba= tArray.Cap.html">http://ocaml-batteries-team.github.com/batteries-included/= hdoc/BatArray.Cap.html

On Wed, Mar 14, 2012 at 5:12 PM, Lukasz Staf= iniak <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.=C2=A0 The same idea wi= th 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 =3D
of_table a in ..., any modification in a will also have effect on cap
and reciprocally."

What I'm thinking about is =C2=A0type +'a Tuple.t with Tuple.of_lis= t and
Tuple.of_array both performing a copy.

--bcaec52be4730c803c04bb3aa153--