[ocaml-platform] An alternative proposal for namespaces

[Gabriel Scherer]

There are some aspects of Alain's proposal I like:

- I'm not particular fond of the foo-bar.cmi trick (yes, it extends
the current OCaml semantics, but I'm not fond of the OCaml semantics
either). I would tend to agree with Alain that having "open namespace
Foo" search through all foo-*.cmi in the search path is a bit of a
mess. On the other hand, I included a "scan" primitive in my original
namespace description language that does exactly that. I think it
could be a reasonable default for installed packages (picking
namespaces from the filesystem's /usr/lib organization), but it's a
dubious choice inside the currently-being-compiled project. So Alain's
point of view of asking that auto-discovery features ultimately
produce a namespace file, that is then used by the compiler, is maybe
a reasonable compromise. Finally, I don't think the foo-bar.cmi
solution adequately handles the semantic status of empty namespaces
vs. non-existing namespaces (that's why I think a tree model is better
than a wide mapping from paths to compunits: there is a notion of
existing but empty subnamespace)

- I also like the idea of strengthening the conflict-handling policy,
complaining by default if merging the namespace descriptions
introduces shadowing. That's was the idea of having a "strict merge"
in the namespace description language (and also a "shallow merge" when
people want quick&dirty convenience). Note that an expressive
signature language (eg. filtering some mappings out of a given
namespace description) could profitably replace cases where shadowing
is currently used. Again, if namespace are to be used in-the-large, I
think "explicit and robust" is to be preferred over "convenient but
maybe fragile".

The rest of the proposal is along the lines of "I want namespace
description to be as low-level as possible to be handled easily by any
sort of tools". I am rather pushing for the expressive side. I think
there are a lot of reasonable ways we could help arbitrary tools to
handle namespaces:
- code sharing (or linking of compiler-libs): if the namespace
description "compiler" is distributed as OCaml code under a liberal
license, not only in-the-distribution tools such that ocamldep and
ocamldoc would be encouraged to use it, bisect and what not would be
encouraged to reuse the library. Of course that may not be ideal for
tools not implemented in OCaml
- tool distribution: Leo suggested something along the names of
"ocamlns <namespace information> -resolve Foo..Bar". That's indeed an
obvious idea that would solve the issue of non-OCaml tools quite
easily. You are free to call "ocamlns <namespace information> -list"
to get the whole mapping (in the format that Alain was presenting for
his low-level, essentially compiled, description files), and cache it
just as you want

(I'm not too convinced by the efficiency argument ("calling an
external program ..."): mapping files are also not a terribly
efficient way to provide information for lookups. In the OCaml-land, a
marshalled hashtable or Map could be fairly more efficient for
example.)

On Wed, Mar 20, 2013 at 2:43 PM, Leo White <lpw25 at cam.ac.uk> wrote:
>>> 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?
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform