[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