Chris Hecker wrote:
> 
> I think this thread is a misunderstanding masquerading as an argument.
> 
> Alex, I think people (well, I do at least :) want to hear what the 
> differences between a namespace and the module system are.  It seems on 
> the face of it that fixing pack's implementation would solve the 
> namespace problem (this was Sven's thought as well), but you don't think 
> so (or think it's the wrong way to fix it), and I'd like to understand 
> why, since you've obviously thought about it a bunch.

I have been discussing this privately with Sven. I didn't 
mean to start another thread on the subject, because I knew 
that inevitably it would lead to big waste of time.

As I have mentioned already, I do not think namespaces are a 
paramount feature in any language. Sven correctly pointed 
out that C is a pretty successful language and it does not 
have namespaces. Of course, this is no excuse.

Namespaces address the issue of resolving, or mapping if you 
prefer, identifiers--actually, module names--to module 
objects--that is to pieces of code, bytecode or native 
equivalently.

In such languages as C or Ocaml, where there are no 
namespaces, this mapping is simply function from strings to 
pieces of code. I argue that this mapping gets a little 
clumsy--and this is common experience--when you have a lot 
of modules, that is, when you have a lot of distinct pieces 
of code which you want to identify indipently of each other.

Module encapsulation à la -pack addresses a different issue. 
Packing eliminates the name clashes by reducing the number 
of distinct modules. A lot of small modules are packed into 
one big one, and, voilà, the name clashes are gone. Yes, but 
this is a side effect. The main effect is that you get one 
big chunk of code which can no longer be refactored into its 
individual components: problems arise whenever one of the 
packed modules defines values which, upon definition, 
immediately perform computations. Even functional values 
could be defined in such a way as to engender a computation.

let f' x = ...

let f =
   let t = Hashtbl.create 1024 in
   fun x -> try Hashtbl.find t x with Not_found ->
     let y = f' x in
       Hashtbl.add x y; y

C has a powerful stripping feature because all computations 
start from main(), so by apply a graph traversal algorithm 
you can figure exactly what functions are called and what 
are not. But in our case computations can arise anywhere. 
This is why ocamlc links all modules that are passed to it, 
regardless of whether they are actually referenced anywhere 
else.

Do you see what the problems are with the module system? The 
module system is great for decomposing a problem into 
reusable units, but the units become much less versatile if 
they are packed together.

Namespace are much more "lightweight" feature. They address 
a specific problem: name clashes. They having nothing to do 
with problem factorization or generic programming. Names 
exist at a syntactic level, so the solution to a problem 
pertaining to identifier names must exist at a syntactic level.

Modules relate to sematics. Namespaces relate to syntax. 
Hence, they are orthogonal concepts. It's that simple.

Basically, the namespace feature expands the resolution 
scheme from names to module objects by adding one formal 
parameter to this mapping. If you'll allow me to use an 
pseudo-Caml syntax, I could say that we have a function
resolution : ~name:string -> module_object

We could (should?) have a mapping
resolution : ~space:string -> ~name:string -> module_object

I hope the pseudo-code I used helped make my point clearer 
rather than more obscure.

Alex

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners