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

[Yaron Minsky]

Can the case of both Core and Async (and opening both of their pervasives
modules) be handled here?  This seems to me to be of fundamental
importance.  If that's missing, then I misunderstood the proposal.
On Mar 18, 2013 7:38 AM, "Leo White" <lpw25 at cam.ac.uk> wrote:

> > The problem with this fixed-syntactic choice is that it hampers
> > composability of namespaces.
>
> This is by design. This feature is only meant to provide support to
> specialised libraries, like Core, that wish to provide their own
> equivalent of the standard library's Pervasives module. We probably
> don't want to encourage its general use. I don't think it will be a
> problem that you can't easily compose the "Core" namespace with the
> standard library's namespace.
>
> > Assume you want to work with namespaces Foo and Bar at the same time.
> > In a hierarchical setting you can build a namespace with two
> > namespaces for Foo and Bar (eg. { A => Foo, B => Bar } ) and this has
> > very simple properties (no conflict/shadowing involved). In a flat
> > setting, or if you want to avoid adding one level of depth, you will
> > rather use (A merge B). What happens then if both A and B have a
> > Pervasives module?
>
> This would be handled like two compilation units with the same name: one
> would shadow the other and so only one would be opened. This is safer
> than having both modules opened, since opening both may result in one
> module partially shadowing another, which is more likely to go
> unnoticed.
>
> > Regarding the proposal as a whole:
> > - I'm curious and not sure: what is the reason to remove hierarchical
> > namespaces from your proposal? At first I believed it was the ongoing
> > tooling discussion with Alain, but he actually objects to
> > non-canonicity of names (as permitted by aliasing) more than your
> > foo-bar-baz hierarchical structure. Which perceived problems are
> > solved by this change?
>
> Despite Alain's concerns, I think that it will not be too difficult to
> handle the tooling for hierarchical namespaces. However, I think it will
> be easier to determine this once the tools have already been updated to
> support flat namespaces.
>
> Similarly, the design choice of shallow merging vs. deep merging for
> opening hierarchical namespaces may be easier to reason about once
> namespaces have been included in the language.
>
> These two issues are important, and require some thought before making a
> full proposal including hierarchical namespaces. Rather than waiting for
> these issues to be resolved, I would rather proceed, in the short term,
> with a proposal for flat namespaces.
>
> > - I believe the proposal is still inadequate, or at least
> > underspecified, with regard to the internal name conflicts problem.
> > What kind of conventions do you envision around your proposal to avoid
> > such conflicts?
>
> In my proposal modules must still have a unique name. This name will be
> reflected in the filename of the ".cmi" file (e.g. Foo#Bar as
> foo-bar.cmi). To avoid long source file names, the name can be specified
> with the "-name" command line argument.
>
> Since I expect people to provide a namespace for their package, I would
> expect the interface for module bar from package foo to be called
> "foo-bar.cmi". If people don't use the same names for their packages
> then this should avoid all naming conflicts.
>
> An alternative mechanism, also supported by my proposal and useful for
> libraries that are compatible with versions of OCaml without namespaces,
> is to name the module bar in the package foo "foo_bar.cmi" and then
> provide a search path file "foo.mlpath" that maps "Foo#Bar" to
> "foo_bar.cmi".
>
> Note that in both these solutions the source file can be named "bar.ml",
> and the "-name" argument used to add the "Foo#" or "Foo_" prefix to the
> name. Build systems could easily add automatic support for these
> conventions.
>
> If people wish to be extra careful then they can use the "-name"
> argument to add whatever additional data they want to the module name to
> ensure that it is unique.
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20130318/4ca4c6ec/attachment.html>