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

[Yaron Minsky]

I agree with your point about settilng deep semantic issues ahead of
syntactic one.  I would however submit that the question of whether
you should:

- Have opens in the language proper, including local opens
- Have renames for namespaces in the language proper

are questions that seem worth settling relatively early, since any
semantics for namespaces that don't support this are likely, I
believe, to be insufficient.

Is there really still much disagreement on this point?  Alain seems at
this point content to include such operations, and I don't fully
understand what objections there are to it at this point.

(I do think the first order of business is to ask questions not of
semantics and mathematical models, but of goals.  It's hard to design
something without knowing what one is trying to achieve.  That said, I
think that bit has been reasonably well settled at this point.)

y

On Thu, Feb 28, 2013 at 10:12 AM, Didier Remy <Didier.Remy at inria.fr> wrote:
>>> 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
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform