From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q2FB5mvK024479
	for <caml-list@sympa-roc.inria.fr>; Thu, 15 Mar 2012 12:05:48 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlkDAI/MYU+GnQCBlGdsb2JhbABDtiUiAQEBAQkLCQkUAySCCQEBBToZNgsYLhR3hXaBeQu6NASNZYI/YwSVYJMPgVs
X-IronPort-AV: E=Sophos;i="4.73,590,1325458800"; 
   d="scan'208";a="149531185"
Received: from shiva.jussieu.fr ([134.157.0.129])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2012 12:05:42 +0100
Received: from hydrogene.pps.jussieu.fr (hydrogene.pps.jussieu.fr [134.157.168.1])
          by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q2FB5GYA023992
          for <caml-list@inria.fr>; Thu, 15 Mar 2012 12:05:29 +0100 (CET)
X-Ids: 168
Received: from localhost (localhost [127.0.0.1])
	by hydrogene.pps.jussieu.fr (Postfix) with ESMTP id 8DE25C0CF0
	for <caml-list@inria.fr>; Thu, 15 Mar 2012 12:05:15 +0100 (CET)
Date: Thu, 15 Mar 2012 12:04:27 +0100
From: Pietro Abate <Pietro.Abate@pps.jussieu.fr>
To: caml-list@inria.fr
Message-ID: <20120315110427.GA12350@zed.irill.org>
References: <20120314201221.GA13221@zed.irill.org>
 <CAPFanBEfyWZRxFhi1jHj5bCVJJ3oztFa2pC2wV4Fn59b_p69Xw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAPFanBEfyWZRxFhi1jHj5bCVJJ3oztFa2pC2wV4Fn59b_p69Xw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Miltered: at jchkmail.jussieu.fr with ID 4F61CCEC.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 4F61CCEC.003/134.157.168.1/hydrogene.pps.jussieu.fr/hydrogene.pps.jussieu.fr/<pietro.abate@pps.jussieu.fr>
Subject: Re: [Caml-list] Arrays and private types

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.