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

Yaron Minsky yminsky at janestreet.com
Tue Feb 26 15:43:57 GMT 2013


On Tue, Feb 26, 2013 at 9:59 AM, Didier Remy <Didier.Remy at inria.fr> wrote:
>> One thing I'll say is that it is important to be able to add values,
>> and not just modules, to the namespace.  Open Core.Std also adds
>> top-level values, as does the traditional standard library (i.e.,
>> Pervasives), and I don't want to lose that.
>
> Yaron,
>
> Do you really need this level of granularity?  I'd like to think of
> modules as the smallest compilation unit.  Can you give us examples of what
> you'd like to do with value manipulation?

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.

There are two reasons for this: the first is to open at the top-level
some constructors and values that are very commonly useful.  Much as
pervasives has None and Some from option available everywhere, we have
Ok and Error from Result.t available everywhere.

Another reason is to shadow values from other modules.  Core.Std hides
various values from Pervasives that we view as harmful.  For example,
we hide ==, and instead expose phys_equal.  (We think == is too
confusing to people from other languages.)

Similarly, Async hides blocking operations that are available in
Core.Std, like print_string, so when you write:

   open Core.Std
   open Async.Std

those problematic values are hidden from.  It would be a shame, I
think, to make every single file that uses Core have to change from:

   open Core.Std

to

   open namespace Core.Std
   open Core.Std.Common

or whatever it would need to be.

y

>     Didier
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform


More information about the Platform mailing list