Re: [Caml-list] Wanted: your feedback on the hierarchy of OCaml Batteries Included

[Nicolas Pouillard <nicolas.pouillard@gmail.com>]

Excerpts from Maxence Guesdon's message of Wed Nov 19 21:11:24 +0100 2008:
> On Wed, 19 Nov 2008 10:46:24 +0100
> "Paolo Donadeo" <p.donadeo@gmail.com> wrote:
> 
> > Couldn't we take inspiration from the Python standard library [1]?
> > Python hasn't namespace but is provided with a module system similar
> > to OCaml *and* the standard library is really impressive.
> > 
> > And nobody can say Python is a bureaucratic language like Java :-)
> > 
> > 
> > [1] http://www.python.org/doc/2.5.2/lib/lib.html
> 
> Hello,
> 
> I think a hierarchy in the documentation is very useful: it helps beginners
> understand the big picture about all available modules and help developers
> find the functions they look for. But in the code, I think it is really
> more convenient to only have one level of "standard" modules.
> 
> By the way, I, too, always prefix idents with the module they come from,
> (like in List.length) and only "open" a module to use fields and
> constructors, so using Data.Containers.List.length or whatever is longer
> than "List.length" is not an option. Having a shortcut "List" for
> Data.Containers.List does not convince me, because the problem will remain
> with modules with no shortcut.
> 
> So hierarchy in documentation: yes; in the code: no.

No one (I guess) would recommend you to use fully qualified paths as in
Data.Containers.List.length of course. Data.Containers.List.length is the
external name, made to be well organized not to be quick to type, the way
to use it to open it *OR* to define an internal name for it :

module L = Data.Containers.List

And then use L.length, L.map...

I know that the choice of name qualification, opening, or local modules is
controversial, however I would like to point out that the external name don't
need to be the same than the internal name.

Cheers,

-- 
Nicolas Pouillard aka Ertai