[ocaml-platform] Unique file names

[Yaron Minsky]

On Mon, Mar 4, 2013 at 9:48 PM, Yaron Minsky <yminsky at janestreet.com> wrote:
> 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.

Apologies: Catching up on the thread, this seems essentially the same
as the -unit-name-prefix proposal that Romain mentions.

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