[ocaml-platform] Followup to Leo's proposal

[Anil Madhavapeddy]

On Mon, Mar 11, 2013 at 09:51:59PM -0400, Yaron Minsky wrote:
> Some thoughts spurred by reading Leo's proposal:
> 
> - AUTO-OPENS ARE NOT JUST FOR CORE.  Leo proposes not having
>   auto-opened modules associated with namespaces, and instead allowing
>   opens to be set at the commandline.  This would not solve our
>   problem, and we would not use them if they were available.
> 
>   It's important to understand Core.Std is not the only example.
>   Another example among our publically released libraries is
>   Async. All Async programs should open Async.Std, which adds a number
>   of important values to the namespace, not just modules.  Indeed,
>   there are many different application frameworks we have where there
>   are a default set of libraries that should be opened as part of
>   opening the namespace.
> 
>   This is a common and highly useful idiom, and one that is well
>   supported by -pack, and I think it should be supported by namespaces
>   as well.  Providing module opens as part of namespaces is both
>   natural from the user perspective (both module opens and and module
>   aliases are namespace manipulations, and thus naturally go
>   together), and important from a usability perspective.

I think our goal should be to eliminate the need for manual open
statements at the top of every file that uses Core or Async.  We've
already seen several cases where people simply forget.  There's also the
important ordering:

open Async.Std
open Core.Std

...is entirely wrong, and is another potential mistake that should be
avoided by removing this boilerplate.

Leo's model allows the build system to precisely set the order of default
opens, and tools such as ocamlfind could support this just as they do
include and link directives at the moment.  I know JS doesn't use
ocamlfind, but the moral equivalent could inject the command-line
directives very easily.

This does make it harder for people using Makefiles directly.  I'm not
sure how much that matters in the case of libraries such as Core, since
all tutorials refer to either OASIS or ocamlfind at the moment.  Of
course, the option to do a manual 'open' is still available in this case.

> - TRUSTING NAMESPACES.  When thinking about whether files should be
>   able to declare their namespaces, one thing that's worth considering
>   is the notion of trust.  The Core library is a particularly closely
>   code-reviewed and tested collection of code, and one can feel pretty
>   safe that if you use anything inside of Core.Std, you're using a
>   pretty trustworthy piece of code.
> 
>   On the other hand, Core_extended.Std is less closely reviewed, and
>   I would want to avoid it for many trusted applications.  Within Jane
>   Street, this is easy for us to manage: we have clear control at the
>   build-system level of what goes into Core.Std, and we can enforce
>   standards of testing and code review on it.

I agree with Jeff here.  You can still maintain this guarantee at the
build system level, and it cripples namespaces if I *cant* extend them in
ways that the original library author didn't want (for example, by
injecting a new module).  This is, after all, what Core does by shadowing
most of the Pervasives module.

-- 
Anil Madhavapeddy                                 http://anil.recoil.org