Would it make sense to issuing warnings in the case of shadowing the Pervasives module? I agree that it makes sense to have Pervasives opened implicitly but only in the context of stdlib-alternatives and paradigm implementing/changing libraries.  In the small it sounds like it could be dangerous --every project having their own library wide coding standard/pervasive module that shadow the stdlib/paradigm shaping libraries should be explicitly frowned upon.<div>
<div><div><br></div><div>Also, what happens if I have a Pervasive module in my project? Would that be opened in each module by default?</div></div><div><br></div><div><br></div><br><div class="gmail_quote">On Mon, Mar 18, 2013 at 11:46 AM, Yaron Minsky <span dir="ltr"><<a href="mailto:yminsky@janestreet.com" target="_blank">yminsky@janestreet.com</a>></span> wrote:<br>
<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 18, 2013 at 11:15 AM, Leo White <<a href="mailto:lpw25@cam.ac.uk">lpw25@cam.ac.uk</a>> wrote:<br>

>> Leo's main argument is that systematically using Pervasives is more<br>
>> predictable for users (that may not want to have to look at namespace<br>
>> descriptions to know which compilation units will be opened by<br>
>> default).<br>
><br>
> That's certainly an argument, but it is not my main one.<br>
><br>
>> I'd say in practice it's rather obvious at medium scale (for any given<br>
>> software project) which module is meant to be the<br>
>> Pervasives/Std/Prelude one, and large scale composability by default<br>
>> could be a better choice.<br>
><br>
> I don't think I've actually suggested providing any means for defining a<br>
> new namespace as the composition of existing namespaces. Nor do I have<br>
> any particular use cases for that feature.<br>
><br>
> However, my proposal does allow a namespace to be specified across<br>
> multiple locations, and it is important that these specifications are<br>
> composable.<br>
><br>
> The ordering between these separate specifications will inevitably be<br>
> under-specified, depending on things like the order of command-line<br>
> arguments. That means that any semantics relying on that ordering will<br>
> be potentially fragile. The best we can hope to achieve is to make sure<br>
> that conflicts between specifications are as obvious to the user as<br>
> possible.<br>
><br>
> We are discussing two possible semantics for "automatically opened<br>
> modules":<br>
><br>
> 1. Supporting a list of auto-opened modules. The automatic open of these<br>
>    modules is morally equivalent to merging their contents into a single<br>
>    "Pervasives" module and then opening that module.<br>
><br>
> 2. Only supporting a single "Pervasives" module. Trying to specify two<br>
>    "Pervasives" modules will simply result in one of those modules being<br>
>    chosen ahead of the other.<br>
><br>
> Of these two semantics, the second one is much more likely to bring<br>
> conflicts to the attention of the user. The first one is more likely to<br>
> hide accidental conflicts resulting in potential bugs.<br>
><br>
> The second semantics also ensures that conflicts between namespace<br>
> specifications only occur at the level of whole compilation units,<br>
> rather than at the level of individual values and types.<br>
><br>
> In summary, any semantics for "automatically opened modules" will not<br>
> compose well. So it would be better to provide a system that obviously<br>
> doesn't compose than to provide a system that pretends to compose, and<br>
> may hide potential bugs.<br>
<br>
</div></div>Just to be clear, do you agree with Gabriel's claim that that<br>
<br>
open namespace A<br>
open namespace B<br>
<br>
will open A#Pervasives and then open B#Pervasives?<br>
<br>
As to your larger point, I basically disagree that the possibility of<br>
shadowing implied by (1) is something to be avoided.  Module opens<br>
behave this way, and within Jane Street we've used them extensively,<br>
using limited, purposeful shadowing, for a decade, and to good effect<br>
as far as I can tell.<br>
<br>
I basically don't see where your belief that automatically opened<br>
modules are semantically problematic and uncomposeable arises from.<br>
Certainly, my experience with packed modules argues in the other<br>
direction.  Do you propose to delete the possibility of shadowing from<br>
the module language as well?<br>
<div class="HOEnZb"><div class="h5"><br>
y<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>
</div></div></blockquote></div><br></div>