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

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

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

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.
It's also unfortunate that if M1, M1.M2 and "M2.ml" all define a value
[foo], it's not possible to open M1, M1.M2 and "M2.ml" in a way which gives
you "M2.ml"'s [foo] (if you follow that highly contrived example...!)


David