[ocaml-platform] Followup to Leo's proposal

[Alain Frisch]

On 03/14/2013 11:02 AM, Leo White wrote:
> http://www.lpw25.net/2013/03/10/ocaml-namespaces.html#Flat+or+hierarchical?

The only use case you mention in this document is "A library may wish to 
provide multiple versions of some of its components".  I still don't see 
why this use case is better treated with hierarchical namespaces than 
flat ones.  One could write Core_testing.  Or one could also support # 
as a valid character in namespace names (i.e. accept Core#Testing 
directly).  The benefit of a hierarchical system would be to support 
writing:

   open namespace Core
   ...
   .... Testing#Mutex ...

With flat namespace, one can do (assuming '#' is a valid character in 
namespace names):

   open namespace Core#Testing
   ...
   .... Mutex ...

or:

   using namespace Core#Testing as Testing
   ...
   .... Testing#Mutex ...


The semantics is simpler to define with flat namespaces and it makes
a qualified reference (Foo#M) very explicit, without having to know 
which namespaces exist, without having to read external files, etc.  You 
only have to look for "using namespace ... as ..." statements in scope 
to know which actual namespace Foo refers to, and ocamldep can trivially 
do it.  In other words, ocamldep can return an exact result (a pair of 
fully resolved namespace name + module name) for qualified references, 
without looking at the file system (for "namespace through filenames") 
or parsing "search path files".  For unqualified references, it needs to 
report for each module name the list of possible (fully resolved) 
namespaces (i.e. the "open namespace" statements in scope).  Again, this 
can be done just by looking at the source code.

I'm thus not convinced by your argument that "none of the systems of 
namespaces that have been proposed have any additional cost for 
supporting hierarchical namespaces".


Having a new mode where ocamldep would do the resolution to actual file 
names (based on search path files) is nice as well, but my understanding 
is that:

   - This does not work with "simple namespaces through filenames" (in 
case of generated source files).

   - This does not play well with the idea of generating the search path 
files themselves during the build (or you need explicit staging).  In my 
experience, such limitations always end up creating tedious problems in 
large code base, even if they look quite minor at first.


Alain