[ocaml-platform] Unique file names

[Alain Frisch]

On 03/03/2013 04:59 PM, Gabriel Scherer wrote:
> Regarding aspect (2), having filename conflicts is not an issue if
> your namespace language is rich enough to let you map two different
> identifiers to two compunits of the same filename.

I did not really specify this part.  As you mention, one can decide that 
.ns files maps names to filenames (probably using relative path to the 
.ns file).

That said, I see it as an advantage to have globally unique filenames, 
for various reasons.  I admit it is an annoyance for library writers, 
but I believe it is a tiny one compared to the benefits of this 
solution.  (As a minor point, my emacs is perfectly fine with 
autocompleting filename based on a suffix following an underscore 
character; e.g. if if type Ctrl-X-F, then "_pricing", then TAB, it 
autocompletes it to apropos_pricing_result.ml.  I don't know if this is 
the default behavior of requires custom configuration, though.)

Some benefits of globally unique filenames:

  - Provide an unambiguous way to refer to a specific compilation unit, 
in a way which only depends on the search path.  While I agree that 
having shorter names "by default" in the documentation or error messages 
is nice, it is also good to support fully explicit outputs, and it is 
better if it does not depend too much on the environment.

  - A corollary to the previous point is to simplify the interface 
between "ocamldep -modules" and the build system.

  - Avoid the need to open compiled files to see "in which namespace" 
they are -- or what their internal name is -- and related problems, 
which we have discussed on this list.

  - Support a deployment scenario where files from many libraries are 
installed in a single directory.

  - Never force library users to use namespaces if they are fine with 
using long names (maybe with the help of a local manual renaming feature).

> Note that Alain's proposal also map the namespace names to .ns
> filenames. My guess would be that if we today recognize that binding
> compunit source-names to their filenames is a mistake, we may regret
> making the exact same choice for the upper-level construct in the
> future.

An alternative could be to specify on the command-line a set of .ns 
files, each of them containing a definition of the "namespace" it 
defines (the name used in the source code).  This would also support 
defining several "namespaces" in a single .ns file.  There was a strong 
resistance to specifying .ns files to be "opened" on the command-line, 
but here we're not talking about opening namespaces, just specifying 
them to the compiler.

In this variant of the proposal, we could almost get rid of -I flags for 
deployed libraries.



Alain