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

[Leo White]

>How about doing that initialization in a more lazy fashion?
>Initializing a module would only create the top level components:
>toplevel values and modules¹, the modules being only "pointers to
>NULL".  when accessing a submodule, the compiler would take note to
>initialize that submodule (and link the corresponding cmo/cmx for
>packed modules²).  If the modules is used in a functor or as a first
>class value, then all submodules present in the signature are
>initialized (this could be on the spot - especially for the toplevel -
>or moved to the place where the module is initialized if that makes a
>difference).  To avoid runtime checks, some static analysis is
>required to make sure that, when a value is used, the corresponding
>submodule has been properly initialized but that may not be too hard.
>
>There are two problems that I can see with this but I think namespaces
>have the same ones if they are to be convenient.  The first is about
>the initialization code in submodules.  As you say, loading a library
>should execute the "toplevel code" of each submodule.  Since this is
>rather infrequent, when building the module record, one may add all
>module paths containing submodules with initialization code.  That way
>the current semantics are preserved and for huge packed modules many
>components should still go away.  However, one could argue that if one
>does not reference the module at all, its initialization code should
>not be executed (alike the behavior one gets when adding cm[x]a on the
>command line).
>
>The second problem is that some toplevel value may need some sumodules
>to be initialized (because they use these submodules).  Some analysis
>is thus required to add these submodules during the record
>initialization.  The same is true when one initialize a submodule that
>was "NULL" before - other submodules may need to be initialized first.
>This analysis may not be too had to do - indeed it is already
>basically present in ocamldep.

Ignoring the fact that this is a dramatic and non-trivial change to the 
language and its implementation, this proposal does not solve the problems 
with pack since it still requires you to link all the modules in the pack 
in case they need to be used (lazily) later on.

It also suffers from a version of my second unhealthy situation: If you do 
anything that requires the runtime representation of the module (e.g. 
"module CS = Core.Std") then you will initialise every sub-module and 
potentially change the semantics of your program.

>I agree that openness may be a desired feature.  Gabriel however said
>that it is not essential. 

I didn't entirely follow what Gabriel said, but I think that he was saying 
a proposal that was locally closed (e.g. within a specific file or using a 
specific namespace definition) could still be globally open. This is 
similar to your suggestion that a "Data" pack could be recompiled/linked to 
add new modules.