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 q2FDJf50028683 for ; Thu, 15 Mar 2012 14:19:41 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQDAG3rYU/RVdK2kWdsb2JhbABDpFyRQQgiAQEBAQkJDQcSKYIJAQEBAwESAiwBGxIMAwELBgULDQ0hIgERAQUBChIZEgkHhW+BdAULnFkKjBCCcYUtP4h0AQULjVqDIgSVYY5IPYQJgVs X-IronPort-AV: E=Sophos;i="4.73,591,1325458800"; d="scan'208";a="136233275" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 15 Mar 2012 14:19:35 +0100 Received: by mail-iy0-f182.google.com with SMTP id k25so6375989iah.27 for ; Thu, 15 Mar 2012 06:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=sOJo2A5BVvB4DY2YcTxtzWU19EandV7yTj4R9ap+Wkk=; b=c7IUKVqqpJm657LBhfiazYR/oyeMRt8Q1foNkMQN0Vx3ggDJ7LhC49vo9Vh4Iqws4F 28YXQi2b8PbVJlMxhk92ZcPVvY6bew5JkXQsO0F4M6OdndXKx2+dUNmVs/GE2nXXhC3c ysosjiLH0ovpIBIcePjhiMZmbwY6ObRxVH6hPLH52qkIFnLqM61XwEh00gLGI6ZJY+Kh QGKlbna3wMqi3ITbWm6EuIN82Tfvbiq4F5Xn57VgVc5M8X5FdGpyENZrQEjASR7vbkAn rKGZMrv/O1VIh7sBAutWpbMenTG13k/pboMV6KkJybIH3dt3qawQ7nJTYfPrXvrDfBj4 KkCg== Received: by 10.42.180.66 with SMTP id bt2mr7314981icb.56.1331817574931; Thu, 15 Mar 2012 06:19:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.3.38 with HTTP; Thu, 15 Mar 2012 06:18:54 -0700 (PDT) In-Reply-To: <20120315110427.GA12350@zed.irill.org> References: <20120314201221.GA13221@zed.irill.org> <20120315110427.GA12350@zed.irill.org> From: Gabriel Scherer Date: Thu, 15 Mar 2012 14:18:54 +0100 Message-ID: To: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q2FDJf50028683 Subject: Re: [Caml-list] Arrays and private types > Thanks Gabriel, very nice solution. If I go this way, I guess there is > no way to access array elements using the usual a.(i) syntax (where i > = M.key i)... [...] > Is this a problem I can solve using a camlp4 decorator ? I don't think you need -- nor want to use -- a camlp4 extension. a.(i) is desugared into (Array.get a i) at a purely syntactical level in OCaml, so you could overload its behavior by changing the Array module in the typing environment. With my example you could write, for example: module A1 = ArrayMake(struct end) let () = let module Array = A1 in let k = A1.key in assert (A1.make 3 true).(k 2);; You could even define the ArrayMake functor so that it returns a structure with an Array submodule. You would then write, using 3.12 "local open" syntax: module A1 = ArrayMake(struct end) let () = let open A1 in assert (Array.make 3 true).(k 2) That said, I don't think that the slight readability benefit of writing a.(i) instead of (get a i) will outweigh the confusion among your readers that don't understand what you're doing with this weird Array stuff. On Thu, Mar 15, 2012 at 12:04 PM, Pietro Abate wrote: > On 15/03/12 00:00, Gabriel Scherer wrote: >> Here is a proposal: >>   https://gitorious.org/gasche-snippets/private-array-keys-type/blobs/master/private_array_key_types.ml >> >> It works by using a functor to generate "fresh" private types for >> keys. Note that the arrays themselves are still polymorphic (no >> IntArray FloatArray etc.). The user still has to use the discipline to >> produce a new application of ArrayMake each time she wants to use a >> different kind of array: if she only does `module A = ArrayMake(struct >> end)` and then use `A` for everything, there will be no additional >> safety guarantee. > > Thanks Gabriel, very nice solution. If I go this way, I guess there is > no way to access array elements using the usual a.(i) syntax (where i > = M.key i)... (I've noticed your cleaver use of private on the array > type to avoid using the normal array syntax on your private arrays). > > Is this a problem I can solve using a camlp4 decorator ? > > This seems a bit complicated as the a.(i) syntax will be context > dependent, that is, the same syntax used with two different array types > should be translated to different get/set calls... and at the camlp4 > level I don't have access to type information... Ideally, instead of > changing all my array access calls, I'd like just to change the type > of my indexes such that all my generic ints will be replaced by > M.key of the appropriate type... > > p > > ps: please do not Cc me. I'm subscribed to the list. > > -- > 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 >