[ocaml-platform] Followup to Leo's proposal

[Alain Frisch]

On 03/13/2013 05:29 PM, Leo White wrote:
> 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.

Since I've not seen a convincing case where hierarchical namespaces 
actually bring something useful, I maintain that the risk of having 
situations as above is sufficient to reject them.

If Core needs to be extendef with a Xml "sub-namespace", let's use the 
flat name "Core_Xml".  If people want to open them, they have "open 
namespace Core_xml".  If they need to occasionally access components of 
this namespace, they can write "Core_xml#Parser.run".  If they don't 
want to open it but still is use frequently, they can alias it "open 
namespace Core_xml as Xml".  (Btw, I find it ugly to use "open" for an 
aliasing feature.  We need a better syntax!)


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



Alain