[ocaml-platform] Followup to Leo's proposal

[Gabriel Scherer]

I think if auto-open is a hard requirement there is no good way around
moving to an ordered model as Didier explained would be needed.

In this semantics, a namespace an ordered mapping from names to
subnamespaces or compilation units, with either (you can choose two
different, equivalent representations)
- some of them marked "flat-access" (the star in the graphical representation)
- an additional stack of unnamed subnamespaces and modules to auto-open

This makes the semantics less simple and elegant, but there is no way
around it we fundamentally on "open" as having a side-effect on the
environment. Ordering matters.

I think name shadowing through "open" is a very bad feature to abuse.
There are some cases where I don't see how to do without it (in
particular the Float.(a + b / c) style of local overloading of infix
operators is a sorely needed feature), but I think that it is wrong to
use it as a general organization principle¹, and that we should
instead promote ways to restrict the signature of a module or
namespace at open time (in particular substracting some names from it,
which cannot be expressed by the current signature language), and have
a stricter default policy regarding open shadowing. Ideally I'd like
something like Haskell's or Agda's "lazy conflict failure", that by
default raises an error as soon as an ambiguous/shadowed name is
*used* in the program.
Note that the rant in this paragraph is not in contradiction with
using an ordered semantics to support the user bases that abuse name
shadowing.

¹: any unrestricted "open" of a third-party library makes the code in
scope not robust to extension of this library, shadowing names from
the outer context. To support upward-compatibility we should strive to
remain monotonic with respect to external code.

On Tue, Mar 12, 2013 at 2:30 PM, Yaron Minsky <yminsky at janestreet.com> wrote:
> On Tue, Mar 12, 2013 at 9:29 AM, Yaron Minsky <yminsky at janestreet.com> wrote:
>> On Tue, Mar 12, 2013 at 9:13 AM, Alain Frisch <alain.frisch at lexifi.com> wrote:
>>> I support the idea of specifying implicit module opens on the command-line.
>>> It is useful independently of the whole namespace discussion.  LexiFi has a
>>> similar local patch; this allows us to provide a "default environment"
>>> (basically, a DSL) for user code to be injected in the application on the
>>> fly (the application manages the compilation itself).  I expect this could
>>> also be useful to Ocisgen (I don't know if it automatically manages
>>> compilation of "user code", but if it does, it probably make sense to open
>>> automatically from infrastructure modules).  Of course, it is trivial to
>>> rewrite the source file to add an "open ..." statement at the beginning, but
>>> I don't see why the official standard library should be the only one which
>>> can be used without any special directive in the source code.
>>
>> I agree this would be useful for many uses --- the DSL case is a
>> particularly important one.  My only point is that it does not in my
>> mind obviate the need to have auto-opens attached to namespaces.
>
> Oh, and to say the obvious: you may well want to specify opens of
> namespaces too (not just modules).  Indeed, if we support specifying
> opens of namespaces, and namespaces can have auto-open modules, one
> feature supports both use-cases.
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform