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

Alain Frisch alain.frisch at lexifi.com
Tue Feb 26 22:17:31 GMT 2013


On 2/26/2013 8:48 PM, Yaron Minsky wrote:
> In short, I'd like to keep the things that affect the meaning of my
> program largely in the source.  I agree that for very pervasive
> things, like Core.Std or sexplib within Jane Street, you may want to
> make this silently present at the build-system level.  But most of the
> time, you want to be explicit about this kind of change to the
> semantics of your program.
>
> Maybe the main difference between us is this: I want to use namespaces
> for multiple libraries, not just highly pervasive ones like Core.  You
> think of namespaces as a thing to solve the fairly narrow problem of
> Core.  If I thought you were right about this, I would agree with the
> rest.

I think we agree on why we disagree.  For me, the only problem which is 
serious enough to justify changes to the language and toolchain is about 
name clashes (not being able to use two libraries together because they 
happen to use identical module names).  A simple non-technical solution 
exists today: a policy to avoid such clashes (long names). The only 
cases where this is problematic, I believe, is for big libraries used in 
a pervasive way, for which (i) long names become really tedious for the 
users; (ii) module aliasing is not enough because the library has many 
modules.  I think this is fairly limited and can be solved by very light 
additions to the toolchain, allowing basically to define "user-land 
stdlibs" (with a context-dependent definition of what a stdlib is).  I 
consider other use cases and "required" features of namespaces as nice 
to have (or not) but not important enough to justify any serious 
addition to the language definition and adaptation of existing tools, 
especially when we are talking about breaking some current invariants 
and properties on which some existing users might rely.


Alain


More information about the Platform mailing list