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 B15F27EF5E for ; Fri, 15 Jul 2016 11:52:42 +0200 (CEST) IronPort-PHdr: 9a23:LLyEUhRlQL+YwL2UDswSHtFc0dpsv+yvbD5Q0YIujvd0So/mwa64ZxyN2/xhgRfzUJnB7Loc0qyN4vimBTBLuMnJmUtBWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/mj6bup9aKPE1hv3mUWftKNhK4rAHc5IE9oLBJDeIP8CbPuWZCYO9MxGlldhq5lhf44dqsrtY4q3wD86Fpy8kVBa7zeqB9Sb1DEBwnNXo07Yvlr0+QYxGI4y5WfmwIkxYAKgzB9xbiRt255ifgv6971TaBFcj7UbkvRT2p7OFgTxq+23RPDCIw7GyC0p84t6lcuh/0/xE= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=dra-news@metastack.com; spf=Pass smtp.mailfrom=dra-news@metastack.com; spf=None smtp.helo=postmaster@outmail149058.authsmtp.co.uk Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=62.13.149.58; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of dra-news@metastack.com designates 62.13.149.58 as permitted sender) identity=mailfrom; client-ip=62.13.149.58; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; 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@outmail149058.authsmtp.co.uk) identity=helo; client-ip=62.13.149.58; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@outmail149058.authsmtp.co.uk"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DwAAAfsohXhzqVDT5chBR8pAAGlGuBexqGAAKBMToSAQEBAQEBAQERAQEBCgsJCSEvgjIVghUBAQQBCAIeEkQIAwIJDQsuGSMbAQEEHgWIGAwBv3wxhWKFFYobBYgohxSJZQGBYIQyiwGMfJAbJQWCCT2BWG2HbgEBAQ X-IPAS-Result: A0DwAAAfsohXhzqVDT5chBR8pAAGlGuBexqGAAKBMToSAQEBAQEBAQERAQEBCgsJCSEvgjIVghUBAQQBCAIeEkQIAwIJDQsuGSMbAQEEHgWIGAwBv3wxhWKFFYobBYgohxSJZQGBYIQyiwGMfJAbJQWCCT2BWG2HbgEBAQ X-IronPort-AV: E=Sophos;i="5.28,367,1464645600"; d="scan'208";a="184904672" Received: from outmail149058.authsmtp.co.uk ([62.13.149.58]) by mail3-smtp-sop.national.inria.fr with ESMTP; 15 Jul 2016 11:52:40 +0200 Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u6F9qe3m010222 for ; Fri, 15 Jul 2016 10:52:40 +0100 (BST) Received: from romulus.metastack.com (114.212-105-213.static.virginmediabusiness.co.uk [213.105.212.114]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u6F9qdNW065660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Jul 2016 10:52:39 +0100 (BST) Received: from Bug ([172.16.0.29]) (authenticated bits=0) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id u6F9qc0o022752 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 15 Jul 2016 10:52:39 +0100 From: "David Allsopp" To: References: <001701d1daa2$30f7ac30$92e70490$@metastack.com> <1468179914.25014.89.camel@e130.lan.sumadev.de> <20160714090300.GB21053@frosties> In-Reply-To: <20160714090300.GB21053@frosties> Date: Fri, 15 Jul 2016 10:52:38 +0100 Organization: MetaStack Solutions Ltd. Message-ID: <002601d1de7e$9f5776d0$de066470$@metastack.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdHaoiY+hN+behtOTfeXtrpVwcHBDAAOQugAAIjFBaAAKfeIgAA1dBzA Content-Language: en-gb X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: de192bcb-4a71-11e6-bcde-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZVg1f DC4bFwdFRBksPQFF ChxFJgxfNlEAUAAU NkdBMnJSNkcdTBdX QSgKXksuFQFuW2N0 bRpQbQ9YYEBNVkto UUtXQ1JXCgdpAwIA BxoBUBxtdksDfgh5 JBIcOXBdWUJ8dQh7 Q0tSWzlTZG5iOjNN TUQJcAJJcQIfeAIX OQQqSXMNYGAGYXwz FlZibyYLEGcXGw9c RwVIKVMJXXNDITcm QREEEi5nGlUIQSQ1 IFQjLVIBGEsKegUt OEBzEU0YIlcTEUVU AkBJDC5fKBEGTCMu CUtaVFQSR3w1 X-Authentic-SMTP: 61633634383431.1038:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 213.105.212.114/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Subject: RE: [Caml-list] Warnings opening modules (was: why is building ocaml hard?) Goswin von Brederlow wrote: > 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? I don't follow what you mean - what I propose changing is that [open Util] would cause a warning and eventually, in some future version of OCaml, be rejected by the compiler. The problem it would solve is that ocamldep/whatever knows that open Foo always refers to a toplevel (or fully qualified) module path. > 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. Indeed, that's my preference, although I'm stupidly picky and actually prefer to write: module Util = ReallyCoolLibraryPack.Util but that comes under my list of "strange habits which normal people don't agree with" :o) I'm allergic to anything which involves a wildcard ([open ReallyCoolLibraryPack] being rather too like writing [import ReallyCoolLibraryPack.*;]) > > > > 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. Possibly addressing a separate problem here. However, that can be fixed (I think) by adding an warning if an open statement shadows locally available modules. e.g. if module FooPack contains module Foo then [open FooPack] would trigger a warning if there is another module Foo either already defined previously in the ml file (for the very ugly case where your [open] statements are littered through your sources!) or if it's defined by having Foo.ml/Foo.cmi/Foo.cmo present. In this case, you'd have to use the form [module Foo = FooPack.Foo] to avoid the warning - and of course you then provide syntax which ocamldep can use to work out the correct dependency. However, that's a problem in both ideas, I think? David