[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