<p dir="ltr">I'm not quite suggesting this seriously, because I haven't thought about the consequences carefully, but what if there was a namespace called Local that one could explicitly open that contained the modules in the local directory?  Then one could write</p>

<p dir="ltr">open namespace Core<br>
open namespace Local</p>
<p dir="ltr">to get the behavior you propose.  Or, you could do it in the other order if that was the shadowing behavior that was preferred.</p>
<p dir="ltr">y</p>
<div class="gmail_quote">On Mar 19, 2013 7:37 AM, "Alain Frisch" <<a href="mailto:alain.frisch@lexifi.com">alain.frisch@lexifi.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/19/2013 11:11 AM, Leo White wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Neither of these options seems particularly problematic to me. The<br>
first one might be more in line with checking that some "foo-*.cmi"<br>
exists when the Foo namespace is opened so that typos produce an error<br>
or warning. But if Sys.readdir is a problem then the second option is<br>
perfectly viable.<br>
</blockquote>
<br>
Sys.readdir is not currently a problem, but it might prevent alternative approaches to discovering dependencies.<br>
<br>
While perfectly viable, the second option will significantly complexify the definition of the typing environment.  We should carefully evaluate the impact on the size of .cmt files and on compilation time (in -bin-annot mode, in particular).<br>

<br>
If I had to choose, I'd probably use the first approach (Sys.readdir).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   (ii) It allows to write more robust code w.r.t. to future additions to namespaces.  With namespaces, library authors<br>
won't hesitate to use "short" names for their modules and the risk is high that a "open namespace" statement hide local<br>
modules when the library is extended.<br>
</blockquote>
<br>
This is basically just an argument against "open namespace" shadowing<br>
things but, as Yaron has said, OCaml uses shadowing all the time and it<br>
doesn't seem to have caused too many problems. If in doubt use explicit<br>
references instead of opens.<br>
</blockquote>
<br>
People have carefully avoided to use common name for modules in libraries, in order to avoid name clashes.  With namespaces, this can changes.  And with the notion of namespaces being more open than module, it's even harder to be sure that opening a namespace will never shadow a local module. The same would actually apply to other units in the current project, not only local modules; so I'd actually propose to look for module in the local namespace -- whatever this means -- first.<br>

<br>
Concretely, if Core adds a new module Foo, this will break all projects using a local Foo module and which "open namespace Core".  A possible solution would be that Core ships many .mlpath files corresponding to module exposed in older releases, so that there is a way to ensure that "open namespace Core" does not bring more modules in scope than before.<br>

<br>
<br>
Alain<br>
______________________________<u></u>_________________<br>
Platform mailing list<br>
<a href="mailto:Platform@lists.ocaml.org" target="_blank">Platform@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/platform" target="_blank">http://lists.ocaml.org/<u></u>listinfo/platform</a><br>
</blockquote></div>