[ocaml-platform] Changes to my previous proposal for namespaces

[Yaron Minsky]

On Mon, Mar 18, 2013 at 11:15 AM, Leo White <lpw25 at cam.ac.uk> wrote:
>> Leo's main argument is that systematically using Pervasives is more
>> predictable for users (that may not want to have to look at namespace
>> descriptions to know which compilation units will be opened by
>> default).
>
> That's certainly an argument, but it is not my main one.
>
>> I'd say in practice it's rather obvious at medium scale (for any given
>> software project) which module is meant to be the
>> Pervasives/Std/Prelude one, and large scale composability by default
>> could be a better choice.
>
> I don't think I've actually suggested providing any means for defining a
> new namespace as the composition of existing namespaces. Nor do I have
> any particular use cases for that feature.
>
> However, my proposal does allow a namespace to be specified across
> multiple locations, and it is important that these specifications are
> composable.
>
> The ordering between these separate specifications will inevitably be
> under-specified, depending on things like the order of command-line
> arguments. That means that any semantics relying on that ordering will
> be potentially fragile. The best we can hope to achieve is to make sure
> that conflicts between specifications are as obvious to the user as
> possible.
>
> We are discussing two possible semantics for "automatically opened
> modules":
>
> 1. Supporting a list of auto-opened modules. The automatic open of these
>    modules is morally equivalent to merging their contents into a single
>    "Pervasives" module and then opening that module.
>
> 2. Only supporting a single "Pervasives" module. Trying to specify two
>    "Pervasives" modules will simply result in one of those modules being
>    chosen ahead of the other.
>
> Of these two semantics, the second one is much more likely to bring
> conflicts to the attention of the user. The first one is more likely to
> hide accidental conflicts resulting in potential bugs.
>
> The second semantics also ensures that conflicts between namespace
> specifications only occur at the level of whole compilation units,
> rather than at the level of individual values and types.
>
> In summary, any semantics for "automatically opened modules" will not
> compose well. So it would be better to provide a system that obviously
> doesn't compose than to provide a system that pretends to compose, and
> may hide potential bugs.

Just to be clear, do you agree with Gabriel's claim that that

open namespace A
open namespace B

will open A#Pervasives and then open B#Pervasives?

As to your larger point, I basically disagree that the possibility of
shadowing implied by (1) is something to be avoided.  Module opens
behave this way, and within Jane Street we've used them extensively,
using limited, purposeful shadowing, for a decade, and to good effect
as far as I can tell.

I basically don't see where your belief that automatically opened
modules are semantically problematic and uncomposeable arises from.
Certainly, my experience with packed modules argues in the other
direction.  Do you propose to delete the possibility of shadowing from
the module language as well?

y