[ocaml-platform] Unique file names

[Edgar Friendly]

On Mon, Mar 4, 2013 at 9:56 AM, Gabriel Scherer
<gabriel.scherer at gmail.com>wrote:

> 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 ...
>
> Why not:

source.ml: require Foo require Bar require Baz require Blah <rest of source>

    ocamlc source.ml

and have the compiler process any namespace files that source.ml depends
on?  Findlib could still be used to manage camlp4 and


> Note that I think automatic
> discovery is a dubious idea (for name conflicts for compilation units,
> it's part of the problem),


I'd argue that it's not the automatic discovery that is the problem, but
the "internal name" conflict problem.  Even totally manual addition of
package directories triggers conflicts.  If we had complete automatic
discovery, the internal name conflict problem would

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.
>
>
I propose using restricted module semantics for namespaces; they're well
understood, powerful and should be easy to implement.

E.



> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20130304/d1868d42/attachment-0001.html>