[ocaml-platform] Followup to Leo's proposal

[Leo White]

> The semantics is simpler to define with flat namespaces and it makes
> a qualified reference (Foo#M) very explicit, without having to know which namespaces exist, without having to read
> external files, etc.  You only have to look for "using namespace ... as ..." statements in scope to know which actual
> namespace Foo refers to, and ocamldep can trivially do it.

Actually, you would still need to look in search path files for
aliases. This would be true for any proposal that allows users to create
their own namespaces from existing modules.

>  In other words, ocamldep can return an exact result (a pair
> of fully resolved namespace name + module name) for qualified references, without looking at the file system (for
> "namespace through filenames") or parsing "search path files".

It would still need to parse search path files.

>  For unqualified references, it needs to report for each
> module name the list of possible (fully resolved) namespaces (i.e. the "open namespace" statements in scope).  Again,
> this can be done just by looking at the source code.

It could do that with hierarchical namespaces, there would just be more
of them. Or it could use a different output format, and then there would
be the same amount of output for flat or hierarchical namespaces.

> Having a new mode where ocamldep would do the resolution to actual file names (based on search path files) is nice as
> well, but my understanding is that:
>
>   - This does not work with "simple namespaces through filenames" (in case of generated source files).

The idea is that the build system would produce a search path file
including mappings for these generated files. So it would work perfectly
fine for generated files that specify their namespace through their
filename. It would also work for generated files whose name will be
defined by a "-name" argument.

>   - This does not play well with the idea of generating the search path files themselves during the build (or you need
> explicit staging).  In my experience, such limitations always end up creating tedious problems in large code base, even
> if they look quite minor at first.

I'm talking about generating a search path file that is just passed to
ocamldep. So rather than running "ocamldep -modules" and then using
information from the build system to interpret it, that information is
encoded as a search path file, and regular ocamldep does the work for
you.