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: Chet Murthy <chet@w...>
Subject: Re: [Caml-list] Alternative proposal: COAN

>>>>> "XL" == Xavier Leroy <xavier.leroy@inria.fr> writes:

    XL> Since day one, the OCaml module system has had "hierarchical"
    XL> namespaces in the form of nested modules.  Without sounding
    XL> too cocky, I'd say that ML doesn't have much to learn from
    XL> Java or Perl in the module department.

    XL> The '-pack' mechanism was introduced in 3.06 to support
    XL> separate compilation of the submodules.  Since it is a recent
    XL> extension, it's not yet stable enough to be used widely, but I
    XL> expect this to change with time.

How *amusing*.

Xavier, while you were doing this, I was hacking together, as a piece
of "research" (but then, I work for an industrial "research" lab, so
you can decide for yourself how much "research" I get to do), a real
module system for Java.

Oh, you say (well, -you- wouldn't say it, and you'd be right not to
;-), doesn't Java *have* a module system?  Nope.  In the same sense
that SML/NJ didn't have a notion of compilation/linkage units, back in
1991, when I first met caml-light, Java doesn't have such a notion,
either.  Heck, Java's "packages" are neither hierarchical, nor do the
enforce enough constraints to provide anything remotely resembling
separate compilation or linking.

The linking of any Java class can cause the linking of any other Java
class.  The compilation of any Java class can cause the compilation of
a large number of other Java classes.  They certainly don't allow the
JIT to do anything remotely resembling static compilation.

For achieving "modularity" of a form which permits separate
compilation, hierarchical namespaces is almost irrelevant.  All its
really good for, is for *naming* classes.

After hacking with Java all these years (the horror, the horror), I've
pretty much concluded that something like findlib, with some
extensions to *name* packages more commodiously, would be almost
perfect.

Once we get our Java version of this modularity done, I'm going to
take a look at what one would have to do to findlib (literally, I
think it comes down to module-naming, and that is *all*) to make it
work for large-scale module-sharing.

I really don't think Caml is far.

And I think you're right, Xavier, that you have nothing to learn from
Java and Perl.  Heck, I based the module system I'm writing for Java,
on the old caml-light "compilation units".

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