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

[Nicholas Lucaroni]

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.

Also, what happens if I have a Pervasive module in my project? Would that
be opened in each module by default?



On Mon, Mar 18, 2013 at 11:46 AM, Yaron Minsky <yminsky at janestreet.com>wrote:

> 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
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20130318/173c52da/attachment-0001.html>