[ocaml-platform] An alternative proposal for namespaces

[Leo White]

>> I don't see how they can resolve aliases manually without knowing, on
>> the end user's machine, the location of all packages relative to the
>> location of their package. This also hard codes the aliases, what if the
>> other package moves?
>
> First, I think it's a bad idea for a package to re-export module from another package.  This is just calling for trouble
> when user read the documentation of the respective libraries, or try to make sense of the error messages.  Providing
> several names for a module in a single package (e.g. Core..List and Core_std..List) can be useful, but I don't see any
> use for more complex operations.
>
> Second, if this is really required, this can be done by generating the "search path file" during installation.

While I think that it is useful for one package to be able to provide an
alias to a module from another package, I certainly don't consider it a
critical use case. So I could be persuaded that aliases weren't worth
the effort in the short term. On the other hand, I also don't see
supporting them causing any real problems.

However, I do think that it would be useful for users to be able to
create their own aliases for modules from packages, and aliases in
search path files provide a mechanism for these. Do you have any
suggestions for alternative mechanisms for supporting such aliases?