[ocaml-platform] Followup to Leo's proposal

[Jeff Meister]

I concur with Yaron on his first point, but I disagree with his second
point.

In support of the idea that Core.Std or Async.Std might include some
modules to automatically open, consider that the default namespace
currently provided in OCaml automatically opens the module Pervasives... to
the OCaml developers, this auto-open feature was clearly valuable. Surely,
third-party libraries may have their own notion of "pervasives", right?
Moreover, as Yaron states, packed modules already support this idiom... it
would be an awful shame if some OCaml users ignored the new namespace
features in favor of packed modules, willing to deal with their
shortcomings to gain their advantages, when these advantages could also be
added to namespaces.

As to the second point: personally, I believe it is more important for the
OCaml community to provide free specification of namespaces within a file
(possibly constructed by the user and not the library author). Part of the
utility of namespaces that I see is the ability to use the author's modules
in a way beyond what he originally intended for his purpose. As you said,
your requirements are easy to control within Jane Street... I don't think
it's important to export these requirements outside Jane Street, unless
other OCaml users have similar needs. I would rather that my build system
do exactly as I specify, rather than try to enforce some namespace-based
security guarantees (in a way that likely would not stand up to malicious
circumvention).


On Mon, Mar 11, 2013 at 6:51 PM, Yaron Minsky <yminsky at gmail.com> 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.
>
> - 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.
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20130311/74fa03aa/attachment.html>