[ocaml-platform] Unique file names

Edgar Friendly thelema314 at gmail.com
Mon Mar 4 14:21:57 GMT 2013


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


More information about the Platform mailing list