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

[Yaron Minsky]

On Mon, Feb 25, 2013 at 5:37 PM, Christophe TROESTLER
<Christophe.Troestler at umons.ac.be> wrote:
> 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.

It's hard to track the thread; there's a lot going on.  But earlier in
this thread, Leo White mentioned it, raising the functor issue in
particular.

> 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.

Indeed.  Maybe someone can explain that to those of us who are less
schooled in compiler internals...

y