[ocaml-platform] An alternative proposal for namespaces

[Leo White]

> On 03/20/2013 12:03 PM, Leo White wrote:
>> None of the above is helped by removing "simple namespaces through
>> filenames": it is all already supported by my proposal.
>
> This is not true.  The good properties I list for a system without "simple namespaces" are lost if these "simple
> namespaces" are to supported by tools.

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.

The lookup process you describe is precisely the lookup process I
described in an earlier post. It works better if you pass it a search
path (that could be generated on the fly by the build system), but it
still works fine if you pass it a search directory containing "simple
namespaces".

>> If you don't
>> like some of the aspects of "simple namespaces through filenames" then
>> simply don't use them.
>
> This does not work: as soon as a feature is supported by the
> compilers, the tools have to support them as well.

But this support does not affect any of the properties you described.

> The
> fact that I don't use "simple namespaces through filenames" does not allow ocamldep, omake, ocamlbuild, ocamldoc, etc to
> not support them.  Extra features can have bad effects, even for people who do not plan to use them.

Yes, but in this case they don't.

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

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

>> The majority of users do not require complex dependency analysis for
>> generated source files. I see no reason to prevent them from using a
>> convenient mechanism for defining namespaces. It is also the only
>> mechanism that is really in keeping with the current design of OCaml.
>
> I consider that the way OCaml interact with the file system has bad consequences w.r.t. to dependency analysis, which
> can be fixed quite easily by letting the compiler and tools know about which files are available.  Introducing
> namespaces is an opportunity to improve the situation, and it also makes it even more important to do so (because we
> want to support naming source files differently from compiled units, which breaks a property on which ocamldep currently
> relies).

For most projects dependency anaylisis is not a big issue, and for the
projects where it is complex we will support search path files. Just
because search path files are more appropriate for some projects doesn't
mean we should force them on all projects. You should only pay for what
you use.


>> The idea is that build systems like ocamlbuild do not *have* to support
>> the "-name" argument. It is there so that the build system *can* support
>> various naming conventions if it wants to. If we specify a particular
>> file format for specifying names then every build system *must*
>> recognise that format.
>
> With -name, the mapping between source file names and compilation units is only local to the build system.  But this
> information is really useful for tools (like the current design of
> ocamldoc or Bisect).  

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.

> Concretely,
> if I write a Makefile manually which uses "-name" as in your proposal, how do I inform ocamldoc about the mapping?  Same
> question for ocamldep.

You use the "-name" argument to tell ocamldoc. If you use a search path
file (as you suggest in your e-mail) then you don't need to tell
ocamldep. 

If you are writing a Makefile manually, how are you going to generate
rules from the search path file, as would be required under your proposal?

>> So either the user must write their own search path file specifying the
>> name of every single compilation unit, or the build system has to
>> generate it. If the build system has to generate it, how is that better
>> than using a direct argument?
>
> Because other tools can parse the file.  Otherwise, the information is left hidden in the build system.

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

> The users already have to list all files in a library.

That depends on your build system. Which is my point, your proposal
forces build systems to behave a certain way.

>  Currently, this information is specified in the build system
> itself.  If users directly write a "search path file" and the build system parses it (for instance to deduce
> automatically which modules to put in the library), there is no more work for the library author, and the information is
> directly made available to other tools.

So build systems should use search path files, instead of their existing
mechanisms to work out what files are part of the project?

Under my proposal, you would simply add a "use namespace Foo" option or a
"get namespaces from directory names" option to your build script. Under
yours I must maintain an up to date mapping of names to files.