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

[Yaron Minsky]

On Fri, Mar 1, 2013 at 3:27 AM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> On 02/28/2013 11:17 PM, Didier Remy wrote:
>>>
>>> I agree with your point about settilng deep semantic issues ahead of
>>> syntactic one.  I would however submit that the question of whether
>>> you should:
>>>
>>> - Have opens in the language proper, including local opens
>>> - Have renames for namespaces in the language proper
>>
>>
>> Yes, this is  the minimal, and probably agreed on.
>
>
> I agree with the first point, but not the second one.  In my proposal, the
> only place where a ".ns" mapping file is referred to is the (local)
> open/using statement:
>
>    open namespace Core  (* --->  loads core.ns *)
>
> In this proposal, I don't think it is important to allow writing
> Core#List.map, since Core_List.map is always available.  Since .ns files are
> only "opened", I don't see the point of renaming them:
>
>   alias namespace C = Core
>   ...
>   open namespace C
>
>
> What would be useful is an aliasing feature for modules (which could serve
> to explain the meaning of .ns files in my proposal).

Aha!  We uncover another difference of opinion!  I wouldn't have
thought that namespaces are "only opened".  I would have thought one
could use namespaces as qualifiers as well.  In other words, were I to
write:

   open namespace Core
   open namespace Async

where the second open shadows some elements of the first (like the
Unix module), I'd still like to be able to explicitly reach in, and
write something like

   Core#Unix

to access Core's Unix library.   Given the desire to use namespaces as
explicit qualifiers, aliasing becomes obviously useful as well, since
you may want to use the qualifier over and over in a small chunk of
code, at which point a short name becomes useful.

so, I think my list of required namespace operations is:

- module-level namespace opens
- local namespace opens
- explicit qualification by namespace
- namespace aliases

y

>> The main question whether namespaces are hierarchical or flat is still not
>> answered
>
>
> I think the question itself assumes that namespaces are a new kind of
> objects (and then we can discuss what is their structure, flat or
> hierarchical, graph with ordered edges, etc).  But again, there are some
> ways to address the needs expressed in this discussion without introducing
> such a notion.  In my proposal, there is one single "space of names" for
> modules and compilation units plus a feature to control the mapping of
> module references to compilation units.  In this context, I don't even know
> how to interpret the question of whether namespaces are hierarchical or
> flat.  This does not mean that this question is pointless, only that it
> pertains only to a given category of solutions for the problems we are
> trying to solve.
>
>
>
> Alain