[ocaml-platform] An alternative proposal for namespaces

[Leo White]

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

The resolution of simple namespaces is much easier than the resolution
of search path files. It is fundamentally the same resolution as OCaml
uses now.

If omake continues to use "ocamldep -modules" then it will have to
implement the resolution strategy. To support *search path files* this
will involve either parsing them itself or using the proposed "ocamlns
... -resolve Foo#Bar". If it switches to using regular "ocamldep" with
generated search path files then it won't need to implement the
resolution strategy anyway.

>   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'm not particularly worried about hypothetical build systems. If you
want to implement such a build system then you should really add hooks
into the OCaml compiler. This argument also assumes that catching
"Sys.file_exists" is fine but catching "Sys.readdir" is impossible.

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

No, the only "problem" caused by simple namespaces is the lack of
support for a hypothetical build system based on capturing file system
accesses, and even this would work fine if you always used search path
files.

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

Not particularly, we are only talking about the lack of a warning
telling you to change the name of a namespace that the file doesn't
actually use.

The warning only exists to point you to the likely cause of a later
error, but since we are talking about precisely the case when there is
no later error then it is not particularly concerning.

We could always combine this warning with the "this namespace is unused"
warning so that the warning is raised more consistently. That might
actually make more sense anyway.

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

I happen to be writing a new version of (the front-end of) ocamldoc for
the platform, which will completely avoid this problem. In the
meantime a "-name" option for each module will work fine.

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

If you are going to look in the generated files anyway then why do you
need an ".mlpath" file? Obviously the source file name would be included
in the files compiled using "-name".