From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTP id 9D5E25D5 for ; Fri, 27 Apr 2018 11:21:42 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.49,335,1520895600"; d="scan'208,217";a="324770686" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 27 Apr 2018 13:21:40 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id 4EB468244E; Fri, 27 Apr 2018 13:21:40 +0200 (CEST) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id A0C8F82416 for ; Fri, 27 Apr 2018 13:21:34 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=elie.canonicimerle@gmail.com; spf=Pass smtp.mailfrom=elie.canonicimerle@gmail.com; spf=None smtp.helo=postmaster@mail-lf0-f46.google.com IronPort-PHdr: =?us-ascii?q?9a23=3Als+NzRwNNvWGZwLXCy+O+j09IxM/srCxBDY+r6Qd?= =?us-ascii?q?0uoeLfad9pjvdHbS+e9qxAeQG9mDsLQc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPbQhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYO/1jcKPAZtMaXXROUdpNVyJPBYO8?= =?us-ascii?q?apEAD+sHPe1Fq4XwqF8DoR64CAKxBu3g1yVIi2f00q000+ovHwLI0hE+Ed0Sq3?= =?us-ascii?q?nbtsn5Ob0IXOyp0KXFzzPOZO5W1zfn74jIdwgsr/6IXbJxb8Xa1FciGBnDjlWX?= =?us-ascii?q?r4zlPi+a1uUQuGac8eVgT+avhHA6oAx2vDevwsYshZfTio0J0F/E8yJ5wIA0Jd?= =?us-ascii?q?KkSU57ZMCrEIFUty6ELIZ2TcYiTHtpuCY+0LEJpZm7fC0TxZkh2hXRZfuHc42S?= =?us-ascii?q?7RLiUuacOS94hG9+d7K7hha97VKsyuj4VsWsyllGtC9Fkt3UunAVzRzT69aHRe?= =?us-ascii?q?Fh/ki/wzqP0gTT5vlFIUAyj6rbKoQuzqQ+lpoJqUjDES72mFn2jK+LbUoo4Omo?= =?us-ascii?q?6+P/brXpp5+cK490ihzlPag0hsO/BuE4PhAOXmeB+eS807rj8VflT7VNi/06iq?= =?us-ascii?q?zZv4rGJcQBp664DBVZ0oMn6xqnFDiqytEYnX0fIFJAYh2Hk5LpO1DBIf/gDPe/?= =?us-ascii?q?hUisnylxx/DAJLLhBo3CIWXEkLfnYbZy81JcyA0uzd9D55JYELQBIPb1V0Tst9?= =?us-ascii?q?LYFgc0PxKoz+vjEtlw1YMTVXiRDqOEMK7eq1CF6+MpLuKRfoEaoiz9JOIg5/P2?= =?us-ascii?q?jX82h1sdfa6x0JsScn+4H/BmL1ydYXrintsNCGkKswU/QeDwh12CVjlTZ3m2X6?= =?us-ascii?q?0i/D00FIWmDYLbSoCshryOwju7E4VIamxaDl2AC3TleoWeV/sSdS6fItVtnzMF?= =?us-ascii?q?WLS5To8uzxCutAv0y7p9KerU/zUVuozn1Nh0+eLfjw09+iZyD8Sa1WGNTn17nm?= =?us-ascii?q?INRzAoxqB/pVJyx0yM0ah9mfNYFNhT6+lVXQc9MJ7Q1/Z6BMzqWgLdYteJT06r?= =?us-ascii?q?Tcm8DjE0StI92tsOY0dmG9W+lR3DxCqrA7oNl7ORHpA086Tc32LwJ8ln0XrG2r?= =?us-ascii?q?Mh3BEaRZ5tKGvup6h46gWbU4zUlQOdnqOgea000yvE9WPFxm2L6hJ2Sgl1BIjB?= =?us-ascii?q?XH1XTULQqtL47UKKarK0DblvZgZFyMPEIaJMbdvohlRDSe3nNfzRZmuwnyG7Ah?= =?us-ascii?q?PeleDEV5bjZ2hIhHaVM0MDiQ1GuCvfbFlsNmKau2vbSQdWOxfqakLo//N5rSri?= =?us-ascii?q?HEAxxgCOKUZm0ujso0JHtbmnU/oWm4k8lmI5sTwtRQSy2tvXD5yLoA8zJPwBM+?= =?us-ascii?q?N4209O0CfijyI4PpGkKPo/1FsXcgAyu022khsrVMNPls8lqH5sxw13e/qV?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BhAQB0BuNafy7XVdFcGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJNgVcXYxUTCoNhgR2CUJEQgXSBD4FAJ5FBgWQLI4MSgTcCgkYHGQc?= =?us-ascii?q?BBDQUAQIBAQEBAQEBAQETAQEJCwsIJiUMgjUkgk8BAQEBAgEjBBkBGxILAQMBC?= =?us-ascii?q?wYDAgsNDR0CAiEBAREBBQEKEgYTCAqEZAEDDQgPjEGQADyLBYFpFgUBF4JwBYN?= =?us-ascii?q?XChkmAwpUV4I9AgYShV6CJIITg2wugk83CwICgRgOZYJTglQChg4IfIR7hGWGb?= =?us-ascii?q?ywIhWSFaYJ9gXGKZIVqg1JFV4VTDwMegQQMJ0eBLE0jUA0NF4ISCYFnJDSDNIE?= =?us-ascii?q?+gSaBPIY0PTCPBII3AQE?= X-IPAS-Result: =?us-ascii?q?A0BhAQB0BuNafy7XVdFcGgEBAQEBAgEBAQEIAQEBAYJNgVc?= =?us-ascii?q?XYxUTCoNhgR2CUJEQgXSBD4FAJ5FBgWQLI4MSgTcCgkYHGQcBBDQUAQIBAQEBA?= =?us-ascii?q?QEBAQETAQEJCwsIJiUMgjUkgk8BAQEBAgEjBBkBGxILAQMBCwYDAgsNDR0CAiE?= =?us-ascii?q?BAREBBQEKEgYTCAqEZAEDDQgPjEGQADyLBYFpFgUBF4JwBYNXChkmAwpUV4I9A?= =?us-ascii?q?gYShV6CJIITg2wugk83CwICgRgOZYJTglQChg4IfIR7hGWGbywIhWSFaYJ9gXG?= =?us-ascii?q?KZIVqg1JFV4VTDwMegQQMJ0eBLE0jUA0NF4ISCYFnJDSDNIE+gSaBPIY0PTCPB?= =?us-ascii?q?II3AQE?= X-IronPort-AV: E=Sophos;i="5.49,335,1520895600"; d="scan'208,217";a="324770633" Received: from mail-lf0-f46.google.com ([209.85.215.46]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Apr 2018 13:21:32 +0200 Received: by mail-lf0-f46.google.com with SMTP id v85-v6so2131769lfa.13 for ; Fri, 27 Apr 2018 04:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IfCl+4FSG7t9ZMJFGAAK34zwSZmpazQdhF74gNccIAM=; b=MwQaQ6p3NrgrR0ksbBTfBUHLkZ+hSKAShZeINHKMYCS9W+QUkSlcJQXcLipuo9gbuD +U0J//Rkn8qw6o+s+8WPfT9VnZM0AU43Ldg9viV57uIaumIeD2gIUuWsU11lU/knpfyS ZM6HJVsNRFIgA2Iuzl06/PjsQwAU4hJHr+n0ORmVasbTBGDJWvNu5JFeAk4mUVo2iuBe Ajfns+qEhphLqW8nvz5fsuXxZa1f7pDCMHetAdtcboqsQ22WAzngQElVbvDmEimey5XH NJa7HkuM/AUOMBBRfFg5smaWzILJtIIAb8BLdZQGP7ywgRtrLhSXbQeRZyGglFLTHKzh hdxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IfCl+4FSG7t9ZMJFGAAK34zwSZmpazQdhF74gNccIAM=; b=dZeR1QbEG4DhUBGK7o7Rr0O/druG0SI8JdduXva1lgn4tx1/fb5O5PEWSS8eSLaWLI BdPddesYHt32FD4qcxrmzuYfhL7aDWaOVr6i3JYMnwTFxNAoXzdXRa6zGQWZsJas4jdz v0WSS2dR5YxGL88xjljzkNjma0ow1/jSTDbKnoNtkIwqc7mP5AEl0cA4jhNOCtImsURR vYK59cy+AHAucDNNMtRYoSkyLWEO2Y8n0pWQGfuyl5LUNAuX1UC885GAI0JEEsb705JY m8DUwOgVSL6Jsbkhg4wZn7F8IX0k7JvWvLTPshauofCIBg1f4+FFD4zcTZS+wlYjxYs6 jkQw== X-Gm-Message-State: ALQs6tBhcsVgYlZlUdtynNyOrKngBPycR87gYBeqj/3928sDTxHGvhJy hQMt3N1VTPyQcegnSpfCQ74j6kSINPE2bWOYBhSLGA== X-Google-Smtp-Source: AB8JxZpfjLTL4gU+Ky2qG2d/VWW2QA96Frzi16VejrW/JE7K4z2gsw95ffJYSxnMhFL7KkUJwpptrlekBG1lQoLGIdg= X-Received: by 2002:a19:8e8e:: with SMTP id a14-v6mr1319583lfl.145.1524828092047; Fri, 27 Apr 2018 04:21:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.157.21 with HTTP; Fri, 27 Apr 2018 04:21:01 -0700 (PDT) In-Reply-To: References: <30D1A366-BDE1-4D6A-9531-A21492C930CE@math.nagoya-u.ac.jp> From: Elie Canonici Merle Date: Fri, 27 Apr 2018 13:21:01 +0200 Message-ID: To: Jun Inoue Cc: Mailing List OCaml Content-Type: multipart/alternative; boundary="000000000000c52510056ad2b461" Subject: Re: [Caml-list] Type That's Concrete From Within A Library Abstract From Without Reply-To: Elie Canonici Merle X-Loop: caml-list@inria.fr X-Sequence: 16862 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000c52510056ad2b461 Content-Type: text/plain; charset="UTF-8" Hi, Do you need to expose that B.t and A.t are the same? Because if you don't it works. $ cat > a.ml type t = Foo of int let x : t = Foo 3 $ cat > b.ml type t = A.t let x2 = A.x $ cat > p.mli module B : sig type t val x2 : t end $ ocamlc -for-pack P -c a.ml b.ml $ ocamlc -c p.mli $ ocamlc -pack -o p.cmo a.cmo b.cmo If you need to expose the type equality you can make it work by adding the signature of the module A while still keeping A.t abstract in p.mli (or not, depending on your needs) $ cat > a.ml type t = Foo of int let x : t = Foo 3 $ cat > b.ml type t = A.t let x2 = A.x $ cat > p.mli module A : sig type t end module B : sig type t = A.t val x2 : t end $ ocamlc -for-pack P -c a.ml b.ml $ ocamlc -c p.mli $ ocamlc -pack -o p.cmo a.cmo b.cmo I hope it helps. 2018-04-27 10:53 GMT+02:00 Jun Inoue : > Hi Jacques, > > OCaml gives a type error if a public type in b.ml references a > non-trivial type in a.ml. Is there a way around this? > > $ cat > a.ml > type t = Foo of int > let x : t = Foo 3 > $ cat > b.ml > type t = A.t > let x2 = A.x > $ cat > p.mli > module B : sig type t = A.t val x2 : t end > $ ocamlc -for-pack P -c a.ml b.ml > $ ocamlc -c p.mli > $ ocamlc -pack -o p.cmo a.cmo b.cmo > File "_none_", line 1: > Error: The implementation (obtained by packing) > does not match the interface p.mli: > In module B: > Modules do not match: > sig type t = A.t val x2 : A.t end > is not included in > sig type t = A.t val x2 : t end > In module B: > Type declarations do not match: > type t = A.t > is not included in > type t = A.t > > > On Fri, Apr 27, 2018 at 3:05 PM, Jacques Garrigue > wrote: > > You can provide a mli for the -pack. > > Just compile it before. > > > > $ cat > a.ml > > type t = int > > let x : int = 3 > > $ cat > b.ml > > let x2 = A.x * A.x > > $ ocamlc -for-pack P a.ml b.ml > > $ cat > p.mli > > module A : sig type t val x : t end > > module B : sig val x2 : int end > > $ ocamlc -c p.mli > > $ ocamlc -pack -o p.cmo a.cmo b.cmo > > > > Now, if you use your library with only p.cmo and p.cmi available, you > will > > only be able to access it through the interface you provided. > > > > Also, the method using module aliases can work too: you just have > > to use longer file names for the internal modules, to reduce the risk of > > conflicts. But this is more involved than using -pack with a mli. > > > > Jacques Garrigue > > > > On 2018/04/27 14:48, Jun Inoue wrote: > >> > >> Hi Ivan, > >> > >> That's basically our current approach, but it doesn't solve the > >> namespace pollution problem. In your example, when someone installs a > >> file named b.cmi (whose interface is unrelated to your b.ml), the name > >> conflict prevents loading the std.cma file at all: > >> > >> $ ocaml > >> OCaml version 4.04.0 > >> > >> # #show B;; > >> module B : sig val foo : int end > >> # #load "std.cma";; > >> The files std.cma and b.cmi disagree over interface B > >> > >> So the technique makes B inaccessible but doesn't remove it from the > >> namespace. This is why we want to -pack things, because our analogue > >> of b.ml is named matrix.ml, and there's no other sensible name for it. > >> > >> This technique doesn't work with -pack because that option demands all > >> .cmi's, including b.cmi. I guess we could rename matrix.ml to > >> matrix_internal_dont_touch.ml, but we wanted to know if there's a > >> cleaner approach. I wish we could supply a .mli file to the product > >> of -pack, but that also doesn't work... > >> > >> On Fri, Apr 27, 2018 at 12:06 AM, Ivan Gotovchits wrote: > >>> Hi Jun, > >>> > >>> You can achieve this by implying an extra layer of indirection, i.e., > by > >>> having two levels of interfaces. For example, > >>> > >>> * A.ml - implementation of module A > >>> * A.mli - private interface of module A > >>> * B.ml - implementation of module B that may rely on anything in > A.mli > >>> * Std.ml - a set of modules that you would like to import, e.g., > `module > >>> A = A`, `module B = B` > >>> * Std.mli - public interface specification > >>> > >>> > >>> Next, you deploy `std.cmxa` and `std.cmi` but keep `a.cmi` and `b.cmi` > to > >>> yourself. This will prevent users from accessing your private modules > A and > >>> B directly. (In oasis you can use PrivateModules stanza for this) > >>> > >>> Now you will have `Std.A` and `Std.B` that exposes as much as you > want. Not > >>> sure whether it will work with the `-pack`, but you can use this > approach > >>> instead of it. This is how we address the same issue in [BAP][1] > >>> > >>> Cheers, > >>> Ivan > >>> > >>> [1]: https://github.com/BinaryAnalysisPlatform/bap > >>> > >>> > >>> On Thu, Apr 26, 2018 at 10:18 AM, Jun Inoue > wrote: > >>>> > >>>> Dear list, > >>>> > >>>> Is there a way to make a type concrete inside a library, yet opaque to > >>>> library users, preferably in a way that works with -pack? This is a > >>>> nagging issue in our sundials package > >>>> (http://inria-parkas.github.io/sundialsml/). > >>>> > >>>> Basically, we have a type declared in one module of the library that > >>>> is pattern-matched upon in other modules, like: > >>>> > >>>> (* private.ml *) > >>>> type opaque_type = Foo | Bar > >>>> > >>>> (* public.ml *) > >>>> let f : opaque_type -> int = function > >>>> | Foo -> 0 > >>>> | Bar -> 1 > >>>> > >>>> There are a few constraints: > >>>> - We don't want users to be able to pattern-match on opaque_type. > >>>> - We need multiple modules in the library to pattern-match on > >>>> opaque-type (so moving opaque_typ e to public.ml is not an option). > >>>> - To avoid namespace pollution, we want to pack the whole library > >>>> (with ocamlc -pack) as a single Sundials module, so the user sees a > >>>> Sundials.Public module instead of just Public. > >>>> > >>>> Is this possible? Right now, we just collect public.cmo and > >>>> private.cmo into sundials.cma and throw away private.cmi. But this > >>>> doesn't work with packing: > >>>> > >>>> $ ocamlc -pack -o sundials.cmo private.cmo public.cmo > >>>> > >>>> demands that there be a private.cmi. > >>>> > >>>> -- > >>>> Jun Inoue > >>>> > >>>> -- > >>>> Caml-list mailing list. Subscription management and archives: > >>>> https://sympa.inria.fr/sympa/arc/caml-list > >>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > >>>> Bug reports: http://caml.inria.fr/bin/caml-bugs > > > > > > > > > > -- > Jun Inoue > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- Caml-list mailing list. Subscription management and archives: https://sympa.inria.fr/sympa/arc/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs --000000000000c52510056ad2b461 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Do you need to expose that B.t and = A.t are the same?

Because if you don't it work= s.

$ cat > a.ml
type t =3D Foo of int
let x : t =3D Foo 3
$ cat > b.ml
type t =3D A.t
<= span style=3D"font-size:12.8px">let x2 =3D A.x
$ cat > p.mli
module B : sig type = t val x2 : t end
$ ocamlc -for-pack P -c a.ml= =C2=A0b.ml
$ ocamlc -c p.mli
$ ocamlc -pack -o p.cmo a.cmo b.cmo<= br>

If you need to expose the type equality you ca= n make it work by adding the signature of the module A while still keeping = A.t abstract in p.mli (or not, depending on your needs)

$ cat > a= .ml
type t =3D Foo of int
let x : t =3D Foo 3
$ cat > b.m= l
type t =3D A.t
let x2 =3D A.x
$ cat > p.mli
module A : sig type= t end
modul= e B : sig type t =3D A.t val x2 : t end
$ ocamlc -for-pack P -c a.ml=C2=A0b.ml
$ ocamlc -c p.mli
$ ocamlc -pack -o p.= cmo a.cmo b.cmo

I hope it helps.


2018-04-27 10:53 GMT+02:00 = Jun Inoue <jun.lambda@gmail.com>:
Hi Jacques,

OCaml gives a type error if a public type in b.ml references a
non-trivial type in a.ml.=C2=A0 Is there a way around this?

$ cat > a.m= l
type t =3D Foo of int
let x : t =3D Foo 3
$ cat > b.m= l
type t =3D A.t
let x2 =3D A.x
$ cat > p.mli
module B : sig type t =3D A.t val x2 : t end
$ ocamlc -for-pack P -c a.ml b.ml
$ ocamlc -c p.mli
$ ocamlc -pack -o p.cmo a.cmo b.cmo
File "_none_", line 1:
Error: The implementation (obtained by packing)
=C2=A0 =C2=A0 =C2=A0 =C2=A0does not match the interface p.mli:
=C2=A0 =C2=A0 =C2=A0 =C2=A0In module B:
=C2=A0 =C2=A0 =C2=A0 =C2=A0Modules do not match:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sig type t =3D A.t val x2 : A.t end
=C2=A0 =C2=A0 =C2=A0 =C2=A0is not included in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sig type t =3D A.t val x2 : t end
=C2=A0 =C2=A0 =C2=A0 =C2=A0In module B:
=C2=A0 =C2=A0 =C2=A0 =C2=A0Type declarations do not match:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type t =3D A.t
=C2=A0 =C2=A0 =C2=A0 =C2=A0is not included in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type t =3D A.t


On Fri, Apr 27, 2018 at 3:05 PM, Jacques Garrigue
<garrigue@math.nagoya-u.= ac.jp> wrote:
> You can provide a mli for the -pack.
> Just compile it before.
>
> $ cat > a.ml
> type t =3D int
> let x : int =3D 3
> $ cat > b.ml
> let x2 =3D A.x * A.x
> $ ocamlc -for-pack P a.ml b.ml
> $ cat > p.mli
> module A : sig type t val x : t end
> module B : sig val x2 : int end
> $ ocamlc -c p.mli
> $ ocamlc -pack -o p.cmo a.cmo b.cmo
>
> Now, if you use your library with only p.cmo and p.cmi available, you = will
> only be able to access it through the interface you provided.
>
> Also, the method using module aliases can work too: you just have
> to use longer file names for the internal modules, to reduce the risk = of
> conflicts. But this is more involved than using -pack with a mli.
>
> Jacques Garrigue
>
> On 2018/04/27 14:48, Jun Inoue wrote:
>>
>> Hi Ivan,
>>
>> That's basically our current approach, but it doesn't solv= e the
>> namespace pollution problem.=C2=A0 In your example, when someone i= nstalls a
>> file named b.cmi (whose interface is unrelated to your b.ml), the name
>> conflict prevents loading the std.cma file at all:
>>
>> $ ocaml
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 OCaml version 4.04.0
>>
>> # #show B;;
>> module B : sig val foo : int end
>> # #load "std.cma";;
>> The files std.cma and b.cmi disagree over interface B
>>
>> So the technique makes B inaccessible but doesn't remove it fr= om the
>> namespace.=C2=A0 This is why we want to -pack things, because our = analogue
>> of b.= ml is named matrix.ml, and there's no other sensible name for it.
>>
>> This technique doesn't work with -pack because that option dem= ands all
>> .cmi's, including b.cmi.=C2=A0 I guess we could rename matrix.ml to=
>> matrix_internal_dont_touch.ml, but we wanted to kno= w if there's a
>> cleaner approach.=C2=A0 I wish we could supply a .mli file to the = product
>> of -pack, but that also doesn't work...
>>
>> On Fri, Apr 27, 2018 at 12:06 AM, Ivan Gotovchits <ivg@ieee.org> wrote:
>>> Hi Jun,
>>>
>>> You can achieve this by implying an extra layer of indirection= , i.e., by
>>> having two levels of interfaces. For example,
>>>
>>>=C2=A0 =C2=A0* A.ml - implementation of module A
>>>=C2=A0 =C2=A0* A.mli - private interface of module A
>>>=C2=A0 =C2=A0* B.ml=C2=A0 - implementation of module B that may= rely on anything in A.mli
>>>=C2=A0 =C2=A0* Std.ml - a set of modules that you would like to= import, e.g., `module
>>> A =3D A`, `module B =3D B`
>>>=C2=A0 =C2=A0* Std.mli - public interface specification
>>>
>>>
>>> Next, you deploy `std.cmxa` and `std.cmi` but keep `a.cmi` and= `b.cmi` to
>>> yourself. This will prevent users from accessing your private = modules A and
>>> B directly. (In oasis you can use PrivateModules stanza for th= is)
>>>
>>> Now you will have `Std.A` and `Std.B` that exposes as much as = you want. Not
>>> sure whether it will work with the `-pack`, but you can use th= is approach
>>> instead of it. This is how we address the same issue in [BAP][= 1]
>>>
>>> Cheers,
>>> Ivan
>>>
>>> [1]: https://github.com/BinaryAnalysi= sPlatform/bap
>>>
>>>
>>> On Thu, Apr 26, 2018 at 10:18 AM, Jun Inoue <jun.lambda@gmail.com> wrote:
>>>>
>>>> Dear list,
>>>>
>>>> Is there a way to make a type concrete inside a library, y= et opaque to
>>>> library users, preferably in a way that works with -pack?= =C2=A0 This is a
>>>> nagging issue in our sundials package
>>>> (http://inria-parkas.github.io/sundia= lsml/).
>>>>
>>>> Basically, we have a type declared in one module of the li= brary that
>>>> is pattern-matched upon in other modules, like:
>>>>
>>>> (* private.ml *)
>>>> type opaque_type =3D Foo | Bar
>>>>
>>>> (* public.ml *)
>>>> let f : opaque_type -> int =3D function
>>>>=C2=A0 | Foo -> 0
>>>>=C2=A0 | Bar -> 1
>>>>
>>>> There are a few constraints:
>>>> - We don't want users to be able to pattern-match on o= paque_type.
>>>> - We need multiple modules in the library to pattern-match= on
>>>> opaque-type (so moving opaque_typ e to public.ml is not an opti= on).
>>>> - To avoid namespace pollution, we want to pack the whole = library
>>>> (with ocamlc -pack) as a single Sundials module, so the us= er sees a
>>>> Sundials.Public module instead of just Public.
>>>>
>>>> Is this possible?=C2=A0 Right now, we just collect public.= cmo and
>>>> private.cmo into sundials.cma and throw away private.cmi.= =C2=A0 But this
>>>> doesn't work with packing:
>>>>
>>>> $ ocamlc -pack -o sundials.cmo private.cmo public.cmo
>>>>
>>>> demands that there be a private.cmi.
>>>>
>>>> --
>>>> Jun Inoue
>>>>
>>>> --
>>>> Caml-list mailing list.=C2=A0 Subscription management and = archives:
>>>> https://sympa.inria.fr/sympa/arc/cam= l-list
>>>> Beginner's list: http://groups.yah= oo.com/group/ocaml_beginners
>>>> Bug reports: http://caml.inria.fr/bin/caml-b= ugs
>
>
>



--
Jun Inoue

--
Caml-list mailing list.=C2=A0 Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--000000000000c52510056ad2b461--