[ocaml-platform] Unique file names

[Gabriel Scherer]

The filenames are important for two distinct reasons now:
1. they determine the "internal name" of the compilation unit (the one
stored in the .cmo/.cmi data); this one must absolutely be unique for
linking to work: you cannot link together two modules of the same
internal name
2. with the current implementation, they determine the mapping from
compilation unit names to compilation units: the current "namespace"
semantics is to map the compunit-name Foo to a file foo.cmi or Foo.cmi
in the search path

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. As far as I
understand, this is currently not the case of Alain's proposal (which
rebinds compunits names to compunits names, still search within the
search-path so not conflict-robust), but some transformations of it
may make it possible (eg. specifying that the compunits specified in a
.ns file are only looked up in the .ns directory, rather than all the
search-path, so that same-filename compunits in distinct repositories
do not conflict); in the general case, a mapping from compilation unit
names to compilation unit paths avoid this issue (but how path are
specified remain to be fully fleshed out: absolute paths, relative to
stdlib, ocamlfind queries...).

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.

Regarding aspect (1), we discussed enriching the compilation unit with
information not coming from the filename itself (eg. the "provenance
field" in spec.pdf). The most general situation is to consider that an
internal prefix (or suffix) can be passed to the compiler at
invocation time, as is currently used -for-pack (you're then free to
express directory-local policies, random choices, interface hashes or
whatever on top of this very primitive idea).

This however opens the door for more things to work out that Alain's
minimalistic proposal avoided. One aspect is the way modules are
referred to in tools output (ocamldoc, ocamldep, etc.). My source my
refer to the compilation unit Foo, which through the compilation
environment resolves to the compilation unit /foo/bar.cm[io]. In
Alain's proposal, ocamldoc would return a reference to the module Bar,
that is the "authoritative" compilation unit name, obtained through
following the namespace rebindings. But if you allow to mix
same-filename compilation units in a project, there is no such
"authoritative" compilation unit name. Ocamldoc output must either
mention the compilation unit path ("/foo/bar") or enhanced internal
name ("janestreet.core.bar.h2d846sc"), which are not very nice, or
refer to the compilation unit name used in the original source file,
Foo, which makes its output relative to the compilation environment
used at invocation time. I personally think this last option is the
way to go (I already consider compilation to be dependent on the
compilation environment, that is the search path filesystem state),
but that is one more subtlety that Alain was happy to avoid.

On Sun, Mar 3, 2013 at 4:17 PM, Daniel Bünzli
<daniel.buenzli at erratique.ch> wrote:
> Le dimanche, 3 mars 2013 à 15:30, Yaron Minsky a écrit :
>> It seems like developers' lives would
>> be simpler (and their ls output full of less repetitive noise) if we
>> don't literally need to name files in this way.
>
> Agreed, if we need to convince him, we could try to quantify the loss of productivity due to editor open/switch buffer completion not being unique while working on a library...
>
> Daniel
>
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform