[ocaml-platform] Unique file names

[Gabriel Scherer]

Regardless of which actual command-line-argument interface we pick for
namespaces, I expect realistic end-users to think in term of ocamlfind
packages, that is

  ocamlfind -package foo,bar,baz,blah source.ml ...

I expect ocamlfind to be updated to support per-library namespaces if
we pick a semantics that allows that (as opposed to namespace choices
being fixed on the code-provider side by a source file header, and
un-changeable after compilation of the compilation unit), so as to
provide a default compilation environment as specified by each package
individually. If the semantics support that, the user could still
refine the compilation environment with private aliases or
hierarchies, and the project-local namespace.

Note that this does not require any automatic discovery feature for
namespaces (or compilation units in fact: we could already get rid of
-I by asking ocamlfind to provide to the compiler the paths to the
compilation units it knows about). Note that I think automatic
discovery is a dubious idea (for name conflicts for compilation units,
it's part of the problem), but would rather keep a single search-path
(for both compilation units and namespaces) if really want some, for
simplicity.

We still need to design an underlying semantics that is more
fine-grained, to be general enough to cover for specific use-cases out
of the ocamlfind-happy world, such as big companies/projects with a
single code hierarchy (JaneStreet, Mirage), or Alain's "everything in
a single big directory" world.

On Mon, Mar 4, 2013 at 3:21 PM, Edgar Friendly <thelema314 at gmail.com> wrote:
> On Mon, Mar 4, 2013 at 7:19 AM, Alain Frisch <alain.frisch at lexifi.com>
> wrote:
>>
>> 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).
>
>
> How about having a namespace include path?  If a namespace Foo were
> referenced in the source code, the file foo.ns would be searched for and
> used to define the Foo namespace.  Maybe even the corresponding compiled
> library could be in the subdirectory foo/ adjacent to the .ns file.  This
> could be made hierarchical later by looking for Foo#Bar as foo/bar.ns.
>
> In this world, library installation would be similar to how findlib works,
> with each project installing a namespace file and a bunch of program
> objects.
>
>>
>> In this variant of the proposal, we could almost get rid of -I flags for
>> deployed libraries.
>>
> The idea of getting rid of -I (for the common case) is one I'm strongly
> behind.  There's no good reason to make it hard to use external libraries.
>
> This way of using namespaces may even allow something unexpected: private
> modules.  When a namespace provides the "interface" to a library, it might
> avoid specifying certain modules implemented by that library.  These
> compunits would still be linked in because of dependencies from other
> compunits in the project, but would not be made available to the
> namespace-using program because the environment modification caused by the
> namespace doesn't make them available.
>>
>>
>>
>> Alain
>>
>> _______________________________________________
>> Platform mailing list
>> Platform at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/platform
>
>