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

[Yaron Minsky]

On Mon, Feb 25, 2013 at 3:43 PM, Christophe TROESTLER
<Christophe.Troestler at umons.ac.be> wrote:
> On Mon, 25 Feb 2013 14:16:03 -0500, Yaron Minsky wrote:
>>
>> On Mon, Feb 25, 2013 at 1:04 PM, Daniel Bünzli
>> <daniel.buenzli at erratique.ch> wrote:
>> >
>> >
>> > Le vendredi, 22 février 2013 à 22:51, Xavier Clerc a écrit :
>> >
>> >> So, as of today, we have :
>> >> - "archives" (cma / cmxa) allowing to gather modules but without
>> >> naming (at the language level) the gathering ;
>> >> - "packs" allowing to gather modules into a module.
>> >> I regard namespaces are gathering modules into a named entity but
>> >> without creating a module. Hence, it is a new beast, different from
>> >> archives and packs.
>> >
>> > So basically a new concept is introduced because "pack" is not
>> > technically satisfying. That's not the way I would like the language
>> > I program in to be designed. I'd rather see the problems pack has
>> > fixed which I'm sure could be done by allowing archives to be named
>> > at the language level as a module.
>>
>> You might be right, but I think there's a deep issue here that
>> shouldn't be dismissed so lightly.  The argument is that modules are
>> simply too powerful to be used as the complete solution to namespace
>> management.  Deciding that the only principled approach is to always
>> pick the most powerful, most general purpose primitive is attractive,
>> but not always sane...
>
> That's an interesting take on this.  Would you care to elaborate on
> why a module approach may not be sane?  Is it from a semantic or an
> implementation point of view?

To be clear: I'm not an expert on the internals of the compiler, and
am mostly repeating claims made by others who are.

But my understanding is roughly this: we want namespaces to behave
differently than modules currently do: in particular, we need to be
able to depend on only a subset of a namespace, and to track
dependencies within the different components of a namespace.

One could imagine building these features into modules directly, but
this is hampered by the fact there is a rich set of operators on
modules, for example, you can apply a functor to a module.

It's of course possible that either (a) one could naturally add these
features to modules directly and thus neatly avoid the need for
another language feature; or (b) that one could have two classes of
modules whose implementations differ under the skin but that present
themselves almost identically to users.

But I am unaware of anyone who understand the compiler internals who
believes either (a) or (b) is reasonably easy to do.

y