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

[Gerd Stolpmann <info@gerd-stolpmann.de>]

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

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.

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

Gerd

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

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]