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

[Wojciech Meyer]

Hi Daniel,

I appreciate your strong stand that we should not introduce redundant
concepts to the language. I can understand that concept of module can
give the impression of managing compilation units. However I think this
is where the similarities end. Given the semantics of OCaml module
system, that each module is separate compilation unit - it's hard to say
it's flexible enough to cover functionality of namespaces which scale up
across the boundaries of compilation units. All the technical problem of
-pack are because modules are not namespaces. So why not to fix it
properly?

In ML world the smallest abstraction available is function, that scale
up to the level of modules, then we have modules that scale up to the
library level, and then we have an empty place that we try to structure
using modules. It would be natural to think that at the library level,
we should not use modules for abstracting and structuring things.

If you are still not sure, please see what SML community have done many
years ago with their compilation manager:

http://www.smlnj.org/doc/CM/index.html

This is an interesting paper. I don't literally repeat what is inside -
as I read this quite long time ago, but it covers a lot more than just
namespace management.

Hope this will make your more confident.

Daniel Bünzli <daniel.buenzli at erratique.ch> writes:

> Le vendredi, 22 février 2013 à 17:40, Leo White a écrit :
>> There is no real reason that something cannot be placed in two locations
>> within the hierarchy.
>
> But as I suggested from the perspective of programming *in the
> language* there no point of having it at two different location. Even
> from the perspective of reading code it's confusing you have to learn
> all the places where a module may be and understand that all these
> modules are in fact the same.
>
>> I agree with this in general. However, there are some specific cases where
>> a hierarchical namespace is very useful. For example:
>>
>> 1. In some very large libraries, it is useful to be able to divide the
>> modules into sub-components that can opened individually.
>>
>> 2. In some libraries it is useful to provide multiple versions of some
>> components (e.g. Foo.Async.Io and Foo.Lwt.Io).
>
> For me all this should be solved within the realm of the module
> system. Maybe we need to fix the way we link things in (since that
> seems to be the only reason why -pack is not deemed reasonable). But I
> really see no point in introducing new namings mechanisms into the
> core language.
>
> Daniel
>
>

--
Wojciech Meyer
http://danmey.org