[ocaml-platform] Followup to Leo's proposal

[Leo White]

> The problem is that this potentially recreates part of the name-collision problem we are trying to avoid.  Doing:
>
> open namespace Core
> open namespace Xml
>
> becomes risky because Core might decide to include an Xml sub-namespace in the future.  And once it does, one cannot
> access the toplevel Xml namespace anymore in the scope where Core is opened.

In the unlikely event that there is a conflict, a simple namespace alias
like:

   open namespace Xml as BaseXml
   [...]
   open namespace Core
   open namespace BaseXml

or a user-written search path file that doesn't define the Xml
sub-namespace of Core would solve the problem.

Of course, we could also just use the "deep" merging semantics for
open. It is possible that this may fit better with how people expect
namespaces to behave.

> Are the limited benefits of hierarchical namespaces worth the trouble?

I really don't think that the benefits of hierarchical namespaces are
that limited.

> Also, I still don't see clearly how ocamldep (with and without modules) will work with your proposal.  In particular,
> will "ocamldep -modules" still have the property to not do any access to the filesystem except for the files explicitly
> passed to it?  I don't see how to preserve this important property without returning only bare module names (with no
> namespace information) as today.  Which means that the resolution logic (from module names to files) will have to be
> redone in the build system (as today), but this logic would be much more complex.  Moreover, since different namespaces
> can be opened in different contexts of the source code, this information should be reported by ocamldep as well (and
> interpreted by the build system).

Actually, I think that "ocamldep -modules" has the property that it will
return the full module name of any possible dependency that the file
could have under any possible search path. By default I would leave this
as it is so that:

    open namespace Foo
    Bar.use

would produce "Foo#Bar" and "Bar" as possible dependencies. This is the
same as it currently does for sub-modules of opened modules.

As you say, it is then the job of the build system to translate these
names into possible file names using the search path. For directories in
the search path this remains simple -- just look for "foo-bar.ml". 

To assist with search path files I would add a new mode for ocamldep (or
maybe a new tool) to support the following call:

    ocamldep -lookup Foo#Bar foo.mlpath

This would one of the following:

- The filename for Foo#Bar found in the path file "foo.mlpath"

- The new module name that Foo#Bar is aliased to in the path file
  "foo.mlpath"

- Some indication that "foo.mlpath" says nothing of Foo#Bar.

This should be sufficient to allow build systems to continue to use
"ocamldep -modules" if they wish. However, a side-effect of adding
search path files is a dramatic improvement in the usability of regular
"ocamldep".

When given a search path file, rather than a directory, ocamldep does
not need to look in the actual directory to check for the existence of a
possible dependency. This means that it can base its dependency
calculation on the files that *will* exist rather than the files that
already do exist.

This means that a build system can produce a search path file containing
mappings for all the files that it could produce (this mapping can
also take account of uses of the "-name" argument). Then it would pass
this search path to ocamldep and get an accurate list of dependencies,
including those on files that have not yet been produced.