[ocaml-platform] on the need and design of OCaml namespaces

[Yaron Minsky]

On Tue, Feb 26, 2013 at 11:43 AM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> On 02/26/2013 04:43 PM, Yaron Minsky wrote:
>>
>> I think we do.  What we want is essentially the same thing that we
>> need to do when OCaml opens Pervasives by default.  We simply have
>> another module that we wish to open by default.
>
> Do you agree that this need of importing values automatically in the global
> scope is quite specific to "stdlib" replacements and to basic
> "infrastructure" libraries?

Infrastructure is a relative question.  Core and Async are both
libraries that want this.  But there are more we have internally.
Indeed, we mint a fair number of little programming worlds, each with
their own conventions that are encoded by such a Std library.  There
aren't hundreds of these, but there are probably a dozen.

Generally, it's important to remember the importance of scale.  Jane
Street has a hundred people actively hacking on OCaml every day,
millions of lines of codes and hundreds of software artifacts.  Things
that seem like occasional special cases become first-class
requirements pretty quick.

> For me, this would justify some "side" support
> for the feature under the form of a command-line option, if this can give
> the expected benefit without touching the language itself.
>
> I expect that most of your code base does "open Core.Std", right?
> What would be the problem of putting this information in the build
> system so that this module is opened by default (and maybe also to
> enable to corresponding "module/unit mapping" with my proposal)?
> Generally speaking I agree that putting too much information in the
> build system is a bad idea, but here the point is precisely to
> provide the illusion that Core.Std is the standard library (for a
> specific code base) and to avoid one extra "open" statement.
>
> There is default behavior of OCaml of opening Pervasives by
> default. This can be switched of.  Now if Core has to be thought as
> a different standard library, why should we require users to even
> write "open Core.Std" at all?  We should be able to arrange so that
> the compiler opens it by default as it usually opens Pervasives.
>
> Again, for me, this is quite orthogonal to module name management (which can
> be useful to many libraries) and is rather specific to stdlib replacement /
> basic infrastructure libraries.

I very much disagree.  This is a common enough primitive that people
should be able to do it without hacking the build system.  Indeed,
Daniel seems to have the same requirements as we do.

y