[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