[ocaml-platform] on the need and design of OCaml namespaces

[Yaron Minsky]

On Tue, Feb 26, 2013 at 1:33 PM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> On 2/26/2013 6:03 PM, Leo White wrote:
>> 2. Alain's proposal provides no means of aliasing namespaces. Similar to
>>     opening a namespace, it would be useful to be able to say "open
>> Core.Std as CS" and then refer to Core_Std_Mutex as "CS#Mutex"
>
>
> I believe that aliasing modules is what matters.  Since I don't understand
> the need for a dedicated notion of namespace yet (with some operations on
> namespaces) I also don't see the need for aliasing them.

Within Jane Street, we alias modules quite a bit (and it would be nice
if this was lighter weight than it is, but that's another story!).  I
think you'd want to alias namespaces for the same reason.

The intuition is this: by default, you want long descriptive
identifiers.  But for a small scope, you're happy to either make the
identifier disappear entirely (as in, [open namespace
Super_awesome_openGL_renderer]) or make it small (as in, [alias
namespace Render = Super_awesome_openGL_renderer).


>> 2. A module's name depends on other files. A module's name (by which I
>>     mean its namespaced name) depends on the ".ns" file, this could
>> definitely be confusing.
>
>
> I don't agree with this interpretation: the name of the module depends only
> on its file name, and we provide a convenient way for client code to refer
> to these modules with shorter names, locally.  It is a big advantage, for
> me, that client code could always be written without "namespaces", if
> required.

I understand why you view this as an advantage, but I think of this as
roughly a disadvantage.  The "namespace" names I think will be far
more usable and convenient, and those I think should be the primary
ones.  I believe the fully-qualified names should be viewed as a
second-class, low-level feature.  For one thing, having both of them
be primary things that are presented to the user is going to be
awfully confusing.

>> 3. They require you to manage an ".ns" file. Not a major burden, but it
>> is    one more place to look for errors. It also must be included in all
>>     calls to the compiler.
>
>
> For any serious use of the compiler with some third-party libraries, the
> command-line is not built by hand, but by your build system and/or
> ocamlfind.
>
>
>> 4. To me they put the namespace information in the wrong place. A
>> component should define its own names, it should also not have to open
>>     its own namespace.
>
>
> I guess this is a matter of taste, and corresponds to a conception of what
> namespaces should be as an identified notion, rather than solving an actual
> need or addressing a concrete problem with my proposal (correct me if I'm
> wrong).

I think it addresses usability of the overall system.  Your approach
of making the flat names priomary maximizes continuity with toolchains
of the past, but also maximizes the confusion of the system to new
users.  I think we should largely present one way of naming things to
users, and making the namespace-names the primary ones seems like a
clear usability win.

>> As a side note, if people are okay with long filenames, why not support
>> having filenames like "core-std-mutex.mli" and then allow "open
>> namespace Core" and "open namespace Core#Std".
>>
>> These could be treated as if there were automatically a "core.ns":
>>
>> namespace Std = "core-std.ns"
>>
>> and "core-std.ns":
>>
>> module Mutex = "core-std-mutex.mli"
>>
>> that were passed to any compiler invocation that had such files on its
>> search path.
>
>
> I don't like this implicitness: how can we infer dependencies?  If ocamldep
> sees a reference to "List" in scope where "open namespace Core" and "open
> namespace Bar" are both active, it would have to look for both core-list and
> bar-list files (and there will be a combinatorial explosion in the
> resolution if you allow opening nested namespaces). Worse: if we use
> "ocamldep -modules", this resolution has to be done by the build system, so
> this complex logic (which depends on the location in the source file) will
> have to be re-implemented in omake and other build systems around.  It is an
> important property that "ocamldep -modules" does not need to look for the
> existence of compiled units on the current tree.
>
>
> Alain