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 ESMTPS id 6F4005D5 for ; Fri, 27 Apr 2018 08:53:44 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.49,334,1520895600"; d="scan'208";a="324736358" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 27 Apr 2018 10:53:42 +0200 Received: by sympa.inria.fr (Postfix, from userid 20132) id B060D8242B; Fri, 27 Apr 2018 10:53:42 +0200 (CEST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 444A582416 for ; Fri, 27 Apr 2018 10:53:35 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=jun.lambda@gmail.com; spf=Pass smtp.mailfrom=jun.lambda@gmail.com; spf=None smtp.helo=postmaster@mail-vk0-f54.google.com IronPort-PHdr: =?us-ascii?q?9a23=3AUXcSDx/5Xdq1iP9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?2uocTK2v8tzYMVDF4r011RmVBd6ds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2O2+55Pebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMNboRr4oRzut86ZrSAfpiC?= =?us-ascii?q?gZMT457HrXgdF0gK5CvR6tuwBzz4vSbY6SKfR+Y7jdfcsESmVdQsZfWStBAoam?= =?us-ascii?q?YIsOCeoKIOJUoob5qlcLqxa1GAuiC/71yjJQhHD206003eoiHw/bwgIvA8kDsG?= =?us-ascii?q?jIoNjvKKseTfy5wavOwD7eb/1WwzD96I3Qfx4lvPGMW697f8nXyUkoCgPKkEib?= =?us-ascii?q?pIvnPzOI0OQBqWyb4PBlVe20lmEosRp8ojeqxsg2i4nJgpgZxUzD9SV82Ys4I8?= =?us-ascii?q?CzRkB8Yd6hCpRQtieaOpN3QsMkWWFouTw1xqcIuZ6hZCQKx5UnxwLfa/yaaIeE?= =?us-ascii?q?+BPjVOGJLTd3hXJlZLK/hwup/kS61uL8Ucy03E5KryVfktnMsXcN2wbP5ciAT/?= =?us-ascii?q?tw+Fqq1zWX1w3L9O1IPUQ5mbDYJpMh2LI8iIcfvErZEiL2l0j7irKdeF8+9eiy?= =?us-ascii?q?8evnZ63rpp+COI9wjQHzKqEulda+AeQ8KwQOQWub9fil2L3t/UD0T69GjvIxkq?= =?us-ascii?q?nev5DaIdoUqrSlDA9S14Yv8xe/DzG439QEhXQLMk5JdRadg4XqO1zCOu70Aeqx?= =?us-ascii?q?jli2kDpmyOjKPrj7DZXMKnjDnq3hfbF460NEygoz0NZf64hQCr4bJfL8QVL+u8?= =?us-ascii?q?bDAx82Ngy72efnCNFn2owCXmKPB7eVMLnOvl+Q+uIvP+6MaZcJtznnLvgl4+fi?= =?us-ascii?q?jXs4mV8GYamkxoAXaXC9HvR+OUqVe3vsgtEbEWcLpAUyVuLqiEfRGQJUMlS7VL?= =?us-ascii?q?sh6ypzJ4u8F4bMW43l1LOIxj26EYBbTmVPFlDKF37ncJSNHupKYSnUINc3wRIe?= =?us-ascii?q?Ur30aZInnTCosxL3g+5lM+yS/iQdv57q/Ndw7uzX0xo18GonXIymz2iRQjQszS?= =?us-ascii?q?szTDgs0fU6/BUkmwWzlJNgivkdLuR9ovZAUwM0L5nZlrUoBNX7WwaHddCMGg//?= =?us-ascii?q?HoeWRAopR9d0+OcgJl5nEoz73B/G1iuuRbQSku7TXcFmwufnx3H0Yv1F5TPG2a?= =?us-ascii?q?0m1QR0R8JOMSi4hfY6+VWPQYHOlEqdmuChcqFOhCM=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAQCA5OJahzbVVdFcDgwBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGDZwE8eigKg2GDbZEPgXQCgQ2BQJFngWQLI4RJAoJFBxkHAQQzFQE?= =?us-ascii?q?CAQEBAQEBAQEBEwEBAQgNCQgoIwyCNSSCSgECAyMEGQEbEgsBAwwGBQsNAgIJH?= =?us-ascii?q?QICIQEBEQEFAQoSBhMShGQBAxUPnGA8iwWBaRYFAReCcAWDWgoZJgMKVFeCPQI?= =?us-ascii?q?GEneEZIIkghODbC6CTzcLAgKBGA6DOIJUAoYOCHyEe2KKbiwIhWOFaIJ9gXGKZ?= =?us-ascii?q?IVqg1NFV4VTDwMegQQygXRNI1ANDReCEgmCCxoagzSBPoEmgTyFeEkwMI57gjc?= =?us-ascii?q?BAQ?= X-IPAS-Result: =?us-ascii?q?A0CLAQCA5OJahzbVVdFcDgwBAQEBAQIBAQEBCAEBAQGDZwE?= =?us-ascii?q?8eigKg2GDbZEPgXQCgQ2BQJFngWQLI4RJAoJFBxkHAQQzFQECAQEBAQEBAQEBE?= =?us-ascii?q?wEBAQgNCQgoIwyCNSSCSgECAyMEGQEbEgsBAwwGBQsNAgIJHQICIQEBEQEFAQo?= =?us-ascii?q?SBhMShGQBAxUPnGA8iwWBaRYFAReCcAWDWgoZJgMKVFeCPQIGEneEZIIkghODb?= =?us-ascii?q?C6CTzcLAgKBGA6DOIJUAoYOCHyEe2KKbiwIhWOFaIJ9gXGKZIVqg1NFV4VTDwM?= =?us-ascii?q?egQQygXRNI1ANDReCEgmCCxoagzSBPoEmgTyFeEkwMI57gjcBAQ?= X-IronPort-AV: E=Sophos;i="5.49,334,1520895600"; d="scan'208";a="263512244" Received: from mail-vk0-f54.google.com ([209.85.213.54]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 Apr 2018 10:53:33 +0200 Received: by mail-vk0-f54.google.com with SMTP id j7-v6so495563vkc.9 for ; Fri, 27 Apr 2018 01:53:33 -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=Exlkd79f/TR7KPavM5Ci7X8CEp4JMbL+rJoSrN/TaJE=; b=Ydy30ZLWwJbmMsGXPXMi0Ofz+G6TL/dk3GrdS3TRjYzgOtlvomAShZWMXio+mOZlBX cgnZWnC/3+EGxYDiZHw2A1eBT7Hcf5YYMAEg2W2IsezZ8LyyOvTegsgxCD1ob/j0wphG jbTTILht544HOqjF8dZwGUjNL17Y9WRGXVUwadKgWjBywa+lwFWomDgWvci69S0bKt7v 0VN836Vx+TbckOuJ8TrcJOHFkt4/eK6+B1Rl1dVdFGLl6gFYr9nfNkXXa98VXMyK6uz0 rPhT94Jqmbj3Ul/8eZ+5i8VW5+pIa5gq8cFNwURuRXk8L+RUkSpeTwv1LGoJB50AE57g XDiw== 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=Exlkd79f/TR7KPavM5Ci7X8CEp4JMbL+rJoSrN/TaJE=; b=N8IQk2AWNiaZP122l6BNBBSbB9Vi+O6mUpEUmcnneqt6LffXRP97hhQbSi88YEOlvl LcXaQmiS2oESmXYd4VFNyRqzOIdQW/FHPmAq3AFV2O++iNjidlQBFadDRoNL1Y4Go6iR 0pDxuSkRvJpnot4PGoM59IKSEa9kjEx+5kYRmLm25P9slcJ2PVg8MM676sAb9yfWSV0c vXzUw+BtcB6blrQ+jAsCFWL9lqQDfKqOs6+J1sXWwFMKBSpPseGq7eJW2r/gKDpTmj+I 1y1QsdAdIxbbtef+3F1SP0PkWjr3C+zU8Wo9MLyaRc5c357gFfaCA8kNcLs5cW/n+UoC uWfQ== X-Gm-Message-State: ALQs6tBFFVMQUKiomryleD/UHCDDFGX9pjZjOxnPfzOusLyu2jA8dTwk om5cIMyFIW6NXCuTWL0RSxVuztiIlPkYpmxkikntHNg7 X-Google-Smtp-Source: AB8JxZoa28nk5K8qRDxzQ1FUbpUa6WpeU+3vlDicDaVA5oBLEQk2svnt8aS18x6yXJJTiaGCAL4uUhamLiQsELs4Fic= X-Received: by 2002:a1f:bf15:: with SMTP id p21-v6mr879226vkf.63.1524819212217; Fri, 27 Apr 2018 01:53:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.68.25 with HTTP; Fri, 27 Apr 2018 01:53:01 -0700 (PDT) In-Reply-To: <30D1A366-BDE1-4D6A-9531-A21492C930CE@math.nagoya-u.ac.jp> References: <30D1A366-BDE1-4D6A-9531-A21492C930CE@math.nagoya-u.ac.jp> From: Jun Inoue Date: Fri, 27 Apr 2018 17:53:01 +0900 Message-ID: To: Jacques Garrigue Cc: Mailing List OCaml Content-Type: text/plain; charset="UTF-8" Subject: Re: [Caml-list] Type That's Concrete From Within A Library Abstract From Without Reply-To: Jun Inoue X-Loop: caml-list@inria.fr X-Sequence: 16861 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: 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