[ocaml-platform] An alternative proposal for namespaces

[Alain Frisch]

On 03/20/2013 01:38 PM, Leo White wrote:
> I don't see any properties described that would be lost by the existance
> of simple namespaces. They are lost if you *use* simple namespaces, but
> they aren't lost simply because the compiler supports them.

If simple namespaces are available, people will use them and sometimes 
encounter weird error messages or broken behavior (such as "open 
namespace Foo" not complaining because of left-overs from an old 
compilation).  It is important to design a system which reduces the risk 
of errors.

Moreover, even if you don't use simple namespaces, you will use tools 
which need to support them.  Concretely, ocamlbuild and the omake 
default rules for OCaml will have to be adapted to support them.  With 
your semantics, omake for instance will have to do a non-trivial job to 
implement the resolution strategy.  Also, the compilers will have to 
scan the directories, preventing other kinds of build systems based on 
capturing accesses to the file system to infer dependencies.   I have 
the feeling to repeat myself...  I can understand that you consider 
these drawbacks as minor, but do you agree they will apply even to users 
not using simple namespaces?


>> Moreover, removing the feature will also reduce the risk of weird behaviors of the compiler and user misunderstandings.
>> In particular, saying that "open namespace Foo" does not fail as soon as their is a "foo-*.cmi" file in one of the -I
>> directories is fragile.
>
> This only affects whether a "Unknown Namespace" warning is
> emitted, and the situation isn't improved by using search path files.

With search path files only, there is no risk to have an old foo-*.cmi 
staying around and changing the behavior of the compiler.  I really hate 
the idea that the compiler behaves differently according to the presence 
or absence on the filesystem of files which are not considered as 
dependencies by the build system!  This is really calling for 
non-reproducible behavior of your build system.

>> Concrete example: the library developers decides to change the name of one of his namespaces
>> from Foo to Bar, but there are old foo-*.cmi files around, so the compiler does not complain upon a remaining "open
>> namespace Foo" in one of the files.
>
> The same thing happens if I accidently leave an old mapping in my search
> path file, except that then the problem won't be fixed the next time I
> run "make clean" or equivalent.

Indeed, so at least you have a reproducible behavior, and the error will 
be easy enough to understand and fix.  Aren't you shocked by the idea 
that while dependencies are correct, you'd get a different behavior from 
the compiler after a "make clean" or a fresh checkout?

> When you use ocamldoc you are supposed to pass it the same arguments
> that you used to compile the program. This is not particularly
> difficult, and is the only way to handle syntax extensions anyway.

With "-name", you can choose a different naming strategy for each file 
in your project.  Ocamldoc is called once to generate the documentation 
for many files.  How do you pass the required information?  With one 
"-name" option for each module?

> But the information is still hidden: Which .mlpath files were used and
> in what order? What "-namespace" argument was passed to the compiler?

As you say, we will need to pass the .mlpath arguments to the tools. 
This is easier than passing a "-name" argument for each module.  And I 
suggested to keep the "-namespace" argument in the generated units 
precisely to avoid having to pass it again to tools.



Alain