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

[Christophe TROESTLER]

On Mon, 25 Feb 2013 16:50:33 -0500, Yaron Minsky wrote:
> 
> 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.

With no doubt, I understand even less about the compiler internals
than you do.  Nonetheless, shouldn't these questions receive a
definitive answer before we speak about namespaces?  I have heard
neither that these things are hard to do.  And, if they are, it would
be interesting to understand what features of modules hamper their
efficiency as simple containers.  That way, it seems to me, either the
technical problems will get solved or what kind of "stripped modules"
namespaces must be will emerge naturally.

Best,
C.