Re: [Caml-list] Warnings opening modules (was: why is building ocaml hard?)

[Goswin von Brederlow <goswin-v-b@web.de>]

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:
> > > <snip>
> > > > 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