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

[Didier Remy]

>> I think the whole discussion of "compilation argument vs. information
>> in source header" is misguided. The two places are essentially
>> isomorphic, and a robust system could make them equi-expressive. In
>> particular, the idea that what putting namespace information outside
>> the source code is a regression is incorrect, as the semantics of an
>> OCaml program *already* depends on the state of the filesystem on
>> which it is compiled and the search path set at compilation time.
>> Namespaces by themselves introduce no regression or improvement on
>> this aspect.
>
> I strongly disagree with this line of argument.  Sure, they are
> technically equally powerful, but that doesn't tell you much.  Good
> programming language design is in part about thinking about people,
> not just about isomorphisms.

I think what Gabriel meant (at least, this is what I think), is that we
should agree on the semantics first and only later care about where
we should place namespace construction commands.

Defining the semantics means:

   - a mathematical model of namespaces: are they flat mappings of strings
     to module objects or trees of module objects? or are they also
     mapping "whatever" to values? Do they carry additional information such
     as auto-open tags?

  - some operations to create and transform namespaces.

  - some operation to invoke namespaces from the core language.

  - a description of the operations in term transformations of the
    namespace, compiler/linker environments.

Gabriel has proposed a model that very view messages refer to in the
discussion.
                               ----------------

Once we agree on the semantics, we somewhat know the maximum we can do with
namespaces.  We then probably wish to restrict what we can do because too
much expressiveness may just invite the user to shoot in his foot.

                               ----------------

Once we agree with the expressiveness that we wish namespaces to provide, we
need to design a small set of constructs not necessarily the same as the
mathematical operations used to described the semantics.  There will be
design choices because there are often several ways to obtain the same
thing.

We will need some syntactic notation. There is absolutely no point in
discussing this so early. Who cares now whether we should use # or \ for
namespace accesses?

Here, we should also decide where operations should go, in separate files,
in command lines, in .ml headers or being inlined anywhere.  Yes, it is
important, as well as the syntax, but it won't change the semantics and
should come later.

                               ----------------

So far, the discussion has mixed all aspects at the same time.  It also
mixes technical questions/problems that may have objective answers with
questions of style, taste, feeling, users, etc. that are much more
subjective in nature.  They are important as well, but they belong to step 2
or 3 and not to step 1.

The discussion is certainly moving---with several hundreds of messages, but
basic aspects of the design such as flat/hierarchical namespaces or should
there be auto-opens, and what should they do hasn't been agreed on yet.

     Didier