<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>