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

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

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

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