<div dir="ltr">On Mon, Mar 4, 2013 at 9:56 AM, Gabriel Scherer <span dir="ltr"><<a href="mailto:gabriel.scherer@gmail.com" target="_blank">gabriel.scherer@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Regardless of which actual command-line-argument interface we pick for<br>
namespaces, I expect realistic end-users to think in term of ocamlfind<br>
packages, that is<br>
<br>
  ocamlfind -package foo,bar,baz,blah <a href="http://source.ml" target="_blank">source.ml</a> ...<br>
<br></blockquote><div style>Why not:</div><div style><br></div><div style><font face="courier new, monospace"><a href="http://source.ml">source.ml</a>: require Foo require Bar require Baz require Blah <rest of source></font></div>
<div style><font face="courier new, monospace"><br></font></div><div style><font face="courier new, monospace">    ocamlc <a href="http://source.ml">source.ml</a> </font></div><div style><br></div><div style>and have the compiler process any namespace files that <a href="http://source.ml">source.ml</a> depends on?  Findlib could still be used to manage camlp4 and </div>
<div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Note that I think automatic<br>
discovery is a dubious idea (for name conflicts for compilation units,<br>
it's part of the problem), </blockquote><div><br></div><div style>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</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We still need to design an underlying semantics that is more<br>
fine-grained, to be general enough to cover for specific use-cases out<br>
of the ocamlfind-happy world, such as big companies/projects with a<br>
single code hierarchy (JaneStreet, Mirage), or Alain's "everything in<br>
a single big directory" world.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div style><br></div><div style>I propose using restricted module semantics for namespaces; they're well understood, powerful and should be easy to implement.</div>
<div style><br></div><div style>E.</div><div style><br></div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">

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