[ocaml-platform] Followup to Leo's proposal
Yaron Minsky
yminsky at gmail.com
Tue Mar 12 01:51:59 GMT 2013
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.
- 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.
If one allows completely free specification of namespaces from
within a file, this could undermine that sense of trust. I'd like
to make sure that we don't undermine the ability to enforce in the
build system that all files for a given namespace come, say, from a
certain directory.
More information about the Platform
mailing list