Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Alternative proposal: COAN
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Xavier Leroy <xavier.leroy@i...>
Subject: [Caml-list] Re: hierarchical modules
> I meant to send this a long time ago, but I forgot.  These are three
> reasons, from least to most important, why I think the -pack feature
> implemented in ocaml 3.06 is not sufficient for hierarchical modules.
> 
> 1. Compiled-in module and file names used for backtrace and assert are
> not fully qualified when using -pack.  I have seen several ambiguous
> backtraces when I used the same module name in two container modules
> (i.e. used the same file name in two directories).
> 
> 2. A module can not be -packed into a container module of the same name.
> 
> 3. I want a separate interface file for the container module. [...]

I agree with point 3.  In addition to the reasons you gave, the .mli
for the container module would be the best place to put its
documentation (for the final user).  One way to implement point 3
would be to do in ocamlc -pack exactly what ocamlc -c does: if there
is no .mli file, synthesize a .cmi interface; otherwise, check
compatibility with the .cmi interface derived from the .mli file.
I'll see if this can be implemented.

Point 2 doesn't seem too serious to me, since having the same name for
a module and one of its submodules is confusing to the final users
(e.g. Module.Module.value).

> I prefer specifying the container module name on the command line or
> adding a "package" declaration to the source file as in Java.

Well, that would be necessary to address your point 1, and would also
remove the dependency on the GNU binutils tools (for ocamlopt -pack).
The one drawback of this approach is that compiled files thus
"pre-packed" could not be linked or loaded in the toplevel, only the
packed container would be; that might make testing a bit harder.

- Xavier Leroy
-------------------
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