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

[David Allsopp <dra-news@metastack.com>]

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.

> > 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?


David