On Thu, Mar 18, 2004 at 01:16:15PM -0800, Kenneth Knowles wrote:

> > it'll get worse. High on my wish-list for the core ocaml system is
> > namespaces or something similiar to help resolve this problem.
> 
> For ocaml, since modules are not first-class, wouldn't it just be a compilation
> frontend issue to do this merging (in addition to some syntax to declare module
> X.Y)?  I'm just pondering, but it seems possible and remarkably useful in order
> to move towards a CPAN-like module repository.  Dependencies between modules
> would naturally cause compile-time failure if they were not present, which is
> desirable.  This seems like one simple step which would enormously increase the
> ability of the community to more effectively contribute libraries and modules,
> and halt a lot of complaints to the INRIA team.


I also think a few more switches in the compiler would mostly put an end to
most complaints and give the community the necessary tools to extend/replace
the libraries. In particular, I feel this is needed:

1) A -pre_open switch that opens a given module (searched along the -I path)
   This would allow people to replace Pervasives with a custom module.

2) -stdlib switches that change the path for the standard library so that
   subsequent -I +path is searched under the current standard library path.
  Several -stdlib switches should be allowed in the same compilation.

3) A firm commitment by the Ocaml team to maintain camlp4 in the future in
   the same terms as the rest of the ocaml core. This would be essential
   for extensions that depend on syntactic manipulation (such regexps) to
   become widespread.

The -pre_open switch seems powerful enough to allow namespace management, since
an extLib module could then be something like this:

extLib.ml:

module List = ExtList
module Array = ExtArray
...

Then, users would be able to switch between the standard library and extLib
without modifying their code by compiling like this:

ocamlc -pre_open extLib.cmo mycode.ml

Fernando

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