[ocaml-platform] Changes to my previous proposal for namespaces

[Alain Frisch]

On 03/19/2013 11:38 AM, Leo White wrote:
> This would prevent one package from providing aliases for modules in
> another package.

What would be a use case for a package providing aliases for modules in 
another package?  This seems likely to create confusion.

And as said, if really required, the same effect can be achieved by 
generating the .mlpath statically (using a tool which would resolve 
aliases, using "ocamldep -lookup").

> So the lookup logic is:
>
>      name := Foo#Baz
>      while there are more paths
>          if !path is a directory then
>              check for file named !name in !path
>              if it found a file then
>                  return the filename
>          else !path is a file
>              run "ocamldep -lookup !name !path"
>              if it found a mapping
>                  if mapping was a filename then
>                      return the filename
>                  else mapping was an alias
>                      name := !alias
>
> So aliases add a single if condition.

So an alias in an .mlpath can only refer to a name defined in the 
directories and search path files that come strictly after the .mlpath 
file on the command-line?  I would have intuitively assumed that this 
would work the other way around (an alias would be interpreted in the 
current scope defined by previous -I directives).

Assuming that package B provides an alias for a module in package A, you 
need to pass "-I B.mlpath" before "-I A.mlpath".  This seems rather 
weird (and fragile).

It's also unfortunate (assuming we really want aliases) that you cannot 
resolve an alias using other lines in the same .mlpath file (this means 
that passing several .mlpath files is not the same as passing a 
concatenation of those files).  I could imagine Core coming with 
something like:

Core#List: "core_list.cmi"
Core_std#List: Core#List



Alain