[ocaml-platform] Followup to Leo's proposal

[Leo White]

> Since I've not seen a convincing case where hierarchical namespaces
> actually bring something useful, 

http://www.lpw25.net/2013/03/10/ocaml-namespaces.html#Flat+or+hierarchical?

> I maintain that the
> risk of having situations as above is sufficient to reject them.

If we use the "deep merging" semantics then that situation can't even
happen.

>> 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.
>
> What about:
>
>  open namespace M1
>  open namespace M2
>  Bar.use
>
> ?
>
> Even with the "shallow" semantics, "ocamldep -modules" cannot know if there is (or will be) a namespace M2.  So do we
> get "M1#Bar", "M2#Bar", "M1#M2#Bar" and "Bar" as possible dependencies?   The size of the output grows exponentially in
> the number of "open namespace"!

Yes but, as I thought was clear in my last post, the correct solution is
to use regular ocamldep with search path files.

We could also add support for search path files to "ocamldep -modules"
but it seems against of the spirit of it. Or we could have "ocamldep
-modules" only produce module names, and have "ocamldep -namespaces"
give a list of namespaces used. Or we could have "ocamldep -modules"
produce something like "(M1,M2)Bar" for your example.