[ocaml-platform] An alternative proposal for namespaces

[Leo White]

> So the "good" mode for using ocamldep would be to have the build system generate a big search path file for each call to
> ocamldep?

I would have thought that it would reuse the same search path file.

>   - How does the build system generate this search path file?  I guess it has to know about the "simple namespaces"
> convention.  Does it?  And does it know about the "-name" arguments scattered around in many subdirectories.

Yes, the build system should now about the "simple namespaces"
convention, although it is a very simple convention ("Foo#Bar :
foo-bar.cmi"). If the build system provides support for alternative
naming conventions then it must also know about them.

>   - How this would work for non-namespaced modules?  Can you represent them with searh path files as in your proposal.
> I thought that search path files only defined namespaced names.

Search path files are allowed for any compilation unit. The whole idea
is that the "search path files" extension is completely independent of
the other extensions in my proposal (and vice-versa).

>   - If you assume that the build system can generate a search path file to avoid calling ocamldep (and thus the compiler
> as well) with any -I 
> directory, what's the point of supporting -I directories any more in the compiler and tools?

For backwards compatibility and convenience. For most projects, the
search path file would simply be a list of the contents of a directory
anyway.


>> As a side note, I think that "ocamldep -modules" should continue to be a
>> purely syntactic version that ignores the search path. It is regular
>> ocamldep that should be used for this purpose.
>
> I propose that "ocamldep -modules" ignores the search path directories, but knows about the definition of namespaces.
> Otherwise, you need to invent a new convention to report possible namespaces together with each module dependency.
>

I think that "ocamldep -modules" should return possible namespaces with
each module dependency. A tool that returns every possible compilation
unit mentioned in a file independent of its search path is probably
useful in general, not just for dependency generation. We can always add
a new mode that is half-way between "ocamldep" and "ocamldep -modules"
(i.e. uses the search path but still returns module names instead of
file names). An "ocamldep -namespaces" that returns all namespaces
mentioned might also be useful.


> And as said, even if you don't believe that is a viable approach for a robust build system, the same approach can be
> used to add extra checks to existing build system that they don't miss dependencies.
>

You could still use such a tool on your own code base, just make sure
that you always use search path files instead of directories (which is
what you are proposing anyway).


>> This kind of behaviour already exists in OCaml. Consider this piece of code:
>>
>>      type t = Bar.t (* Bar only contains type definitions *)
>>
>> If you rename bar.mli to baz.mli but don't remove bar.cmi then it will
>> continue to compile until you run "make clean".
>
> Yes, and I see it as a problem.  I would actually prefer a system where one must pass explicitly to the compiler the
> list of files it can use, but this is not possible because of backward compatibility.  Since namespaces change the way
> OCaml interact with the file system anyway and we have this nice notion of explicitly listing available units in
> well-defined files (which can be used by other tools), I think it's a good opportunity to fix the existing problems
> (partially).

My point is that since you are only fixing it partially, it is not a
good reason for excluding a feature. Especially when there is a clear
way to avoid the problem in your own code: always use search path
files.

Note that using an external library that uses "simple namespaces" will
not cause your own builds to have this problem.


> The average user who creates a library to be used by others will need to pick a good namespace
> name and list which files constitute the library.  

This is not the case. I do not currently have to write a list of files
in my libraries. As I said, it depends on which build system you use.

> At this point, writing an explicit .mlpath file does not add any
> burden (the same source of information can be used to define the
> content of the library).

Note that you don't just have to write these files after you have
finished the library, you must maintain them throughout development.