From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 186B27EF5E for ; Thu, 14 Jul 2016 11:03:06 +0200 (CEST) IronPort-PHdr: 9a23:iVR8yxb6wEroNAb2hFs/fk7/LSx+4OfEezUN459isYplN5qZpc+8bnLW6fgltlLVR4KTs6sC0LuO9fy6EjRQqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i760zceF13FOBZvIaytQ8iJ3pzxi7r5o82bSj4LrQL1Wal1IhSyoFeZnegtqqwmFJwMzADUqGBDYeVcyDAgD1uSmxHh+pX4p8Y7oGwD884mosVJVKG/e6UjUZRZCi4nOiY7/p7Frx7GGCSI/WQdVC0IlRwAKRLI4BzgWpDu+n/1sfFi2S/fI4j8Za85U3Ku4vE4G1fTlC4bOmthoynsgctqgfcDrQ== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=goswin-v-b@web.de; spf=Pass smtp.mailfrom=goswin-v-b@web.de; spf=None smtp.helo=postmaster@mout.web.de Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.15.14; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of goswin-v-b@web.de designates 212.227.15.14 as permitted sender) identity=mailfrom; client-ip=212.227.15.14; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.15.14; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CIAAAqVIdXhw4P49RchBR8sFCIGIF7GoV/AoE3OhIBAQEBAQEBAREBAQEIDQkJIS+CMhWCFQEBBAE6RAsLGAklDwUoiEkBEggEu1UfhFsBAQgCASSKd4dsgi8FmR+GEog9gkOHCAqFZpAZJAGCSYFZbIk3AQEB X-IPAS-Result: A0CIAAAqVIdXhw4P49RchBR8sFCIGIF7GoV/AoE3OhIBAQEBAQEBAREBAQEIDQkJIS+CMhWCFQEBBAE6RAsLGAklDwUoiEkBEggEu1UfhFsBAQgCASSKd4dsgi8FmR+GEog9gkOHCAqFZpAZJAGCSYFZbIk3AQEB X-IronPort-AV: E=Sophos;i="5.28,361,1464645600"; d="scan'208";a="184821950" Received: from mout.web.de ([212.227.15.14]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jul 2016 11:03:05 +0200 Received: from frosties.localnet ([134.3.242.84]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MgfH5-1bhbZg3QT1-00O2sJ for ; Thu, 14 Jul 2016 11:03:04 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.87) (envelope-from ) id 1bNcXt-0005aH-Ec for caml-list@inria.fr; Thu, 14 Jul 2016 11:03:01 +0200 Date: Thu, 14 Jul 2016 11:03:01 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20160714090300.GB21053@frosties> References: <001701d1daa2$30f7ac30$92e70490$@metastack.com> <1468179914.25014.89.camel@e130.lan.sumadev.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) X-Provags-ID: V03:K0:MeNLcgzWlZOs1tt/0wjWYxQEHNX0Fm1KiGMbAVQTUg/wzX9vV7x AUgMDdhOHteVOkwWp4E1eu2JzUJNOpKgudVWixPKhfHanLpdMuanug3ULbKt44waTY0R+Yh 2pl+G+qRfQFNasOW0IhokpFXohwUQB49urlmAbNFRWZzbFU6D+zhbEVkoyPthe/nqhCGgRe 4ZiGC2AKRa3yx9/nYKnvQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:KcQiyznTIkM=:n6ji1LMA2Bc1wSGb9DEfij NdPMDf+afiyF1yvht1FR6KPFZxg8S2+8qirbDFs/OjF4kUqeYl6R3knfQ6v+gP/XhRxIWBMoW 6OVT8PLeyzT7B74xZfhtaGf6x7ThB69s7knHUqEfPR46NOX4cJE0DoDO+/OUnltlWE9PMgo2n f0gyzMa7Zt4NQ5AQzXaqhc/yEdMYcSG6bprbjGBRdcNcVc2quNo7kUMM9/9umAPsEgh1F9pRs jc+3MzEaPQZ1APJjsFitN9wWHU+bJAjkXzDFXpXc0fb5IuEoij/bDNbHCR6KxG2jS/R22dFW6 iG35Wp6VEMzWUzE0P9Nasthfpet1nibn8qj7t1CYryHQnrf8/3v/CLOPbQb1xChtQr0BcQctO OdnZjnPLuftDHDOVw9YmAcbMWxptHt2xS6cmIspw0FMpUxHknTXu7GbHCDKvVN8Di/4whWxpJ GSFRzR62gwR7dSHY6C/+G1emERmiWi4cFz9wMX60V6RjXWaZJJ1/AVGN86ufoxjIOgxOFePQC 5+u8JV77aIaqiVqjWWnqD52Ph1mxCWsnnQAO3z8A5oDu2m2a+z9qrzZ7hcyV7nx/3fEO8/uWj Qvyo5WhUP/9lY4MCr+llFi2zOl/77sOqZq9S2nvutdXqBAYWY67BF9f5BY3Qdf50uQRGV/u2s WNEcQ17aXOuhIDXBj6+bYuyZsHyp0ZF870eiuIM582/qxV8L7NIvxZXjNDAg2q2wOYGpcYA8U p5yEPPUUYLvK2uqMJ2YP4yQRDLL42CpLGYtw4b+S8HykV1HYgNH6ZF0Q8vw= Subject: Re: [Caml-list] Warnings opening modules (was: why is building ocaml hard?) On Wed, Jul 13, 2016 at 12:08:30PM +0000, David Allsopp wrote: > Gerd Stolpmann wrote: > > Am Sonntag, den 10.07.2016, 12:57 +0100 schrieb David Allsopp: > > > Gerd Stolpmann wrote: > > > > > > > For example, when there is > > > > > > > > open M1 > > > > open M2 > > > > > > > > at the beginning of a file, ocamldep doesn't know whether M2 is > > > > another top-level module, or whether it is a submodule of M1. > > > > ocamldep normally errs on the side of generating too many > > > > dependencies, which is then tried to be corrected by only accepting > > > > those deps corresponding to existing files. In this example, this > > > > would mean that a dependency to M2 is emitted when there is a file > > > > M2.ml. Note that this is wrong when M2 is actually a submodule of M1 > > > > AND the file M2.ml > > > exists. > > > > > > I hate the open statement (indeed, I hate its equivalent in every > > > language I've ever used), which limits how much I tend to consider it: > > > but this is awful in so many ways. Do you happen to know how common it > > > is to open one module and then open a *unqualified* submodule of that > > > (i.e. where M2 is a submodule of M1)? > > > > I cannot give numbers, but imagine M2 is actually called Types or Util. > > This trap is a real one. It is not one that makes the build tools > > completely unusable, but it adds a litte bit of the unreliability that is > > observed by the users. If we want to address these issues ocamldep needs > > to be part of this effort. > > > > Successive opens are quite normal when you have packed libraries. > > Sure, but in which case, isn't encouraging (and eventually mandating) > > open ReallyCoolLibraryPack.Util > > considerably better than: > > open ReallyCoolLibraryPack > (* myriad more open statements *) > open Util > > and eventually solves considerably more problems. How does that change anything? A (for me) more common code would be: open ReallyCoolLibraryPack (* myriad more open statements *) Util.foo bla baz module Bla = Util.MAKE(M : FOOABLE) You still get the same dependency on ReallyCoolLibraryPack.Util, ReallyCoolLibraryPack.Util.MAKE, ReallyCoolLibraryPack.FOOABLE, ... without successive opens. > > > It strikes me that that pattern requires not a new language convention > > > as you go on to say, but at least two warnings and possibly a > > > deprecation to discourage its ever being written! The first warning > > > (including a deprecation message) should state that [open M2] relies > > > on the previous [open M1] (similar idea as Warning 40) and the second > > > warning should trigger if M2.cmi also exists indicating that M1.M2 has > > > been opened rather than the actual M2 module (again, with a > > > deprecation message). Both warnings being eliminated by giving: > > > > > > open M1 > > > open M1.M2 > > > > > > The big stability nightmare that I see there is you have: > > > > > > open ThirdPartyLibrary > > > open MyOwnProjectModule > > > > > > and a new version of ThirdPartyLibrary adds a submodule > > MyOwnProjectModule. > > > > I think that we need a syntax for toplevel module paths (e.g. I suggested > > "open ^MyOwnProjectModule", resembling anchored regular expressions). > > Indeed, but rather than adding yet another piece of syntax, does it cause so much pain to move in the direction of just making the open declaration always require a toplevel module path? It's not just open but every module path anywhere. > David MfG Goswin