[ocaml-platform] Unique file names

[Yaron Minsky]

On Mon, Mar 4, 2013 at 7:19 AM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> 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).

Could all of these benefits be obtained by having longer names for
files generated as part of the compilation (.cmx, .cmo, .cmi, etc.),
but keep the source file names short?  i.e., one could imagine that if
you put "-put-in-namespace core" on the command-line to ocamlc, it
would generate "core_list.ml" when given the file "list.ml".  The onus
would be on the build system to provide said flags, but it would seem
to simplify things thereupon.

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

As one of the people who objected to "opening" from the command line,
I have no objection to this.

> In this variant of the proposal, we could almost get rid of -I flags for
> deployed libraries.
>
>
>
> Alain
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform