Re: [Caml-list] choosing modules at runtime

[Alessandro Baretta <alex@baretta.com>]

I just realize that only John Max Skaller got this message. 
I am now sending it to the list, for which it was intended.

Alex

John Max Skaller wrote:
 > Markus Mottl wrote:
 >
 >> On Tue, 24 Sep 2002, 
Sebastien.deMentendeHorne@electrabel.com wrote:
 >
 >
 >> Actually, I'd say that most problems of "programming in 
the large" can
 >> be and are best solved statically. But in some cases, 
one needs more
 >> dynamic means of parameterization.

There's a bunch of people in the Java community who might 
disagree.

 > It is a nice specification that clearly admits its own 
weakness.
 >
 > It is possible to have a purely static solution to almost
 > any problem. The simple demonstration is that you can write
 > an interpreter -- add one more level of indirection.
 >
 > ...
 >
 > Which implies dynamic loading is a mandatory feature
 > for solving general problems.

Very true. A concrete business example: I will be deploying
this week a program I wrote which uses PXP to interpret XML
templates, to format a datastructure built by a Dynlinked
module. The datastructure could be built by parsing an ASCII
file (as is the present case) or by executing a query on a
database or by parsing an XML document downloaded from an
intranet server or in any other conceivable way. This is a
polymorphic problem class which admits only solutions
comprising runtime parametrization, both is terms of
data--the XML templates--and of code.

Coincidentally, I have recently come across the GCC Java
project. (http://gcc.gnu.org/java) They have a compiler with
   both a bytecode and a native backend, much like Ocaml. In
addition they get a native runtime system which is more
flexible than either the JVM or ocamlrun in that it enables
both byte-compiled and natively compiled classes to be
linked dynamically and automatically with the usual
classpath resolution strategy. This might be the way to go
for Ocaml, too, with the possible exception of the classpath
thing, which we sort of agreed against.

One example: I'd love to write a generic client application
capable of connecting with a database server for the data
and to a remote repository of compiled modules implementing
the logic of different application tasks the customer wishes
the system to automate. Dynlink already partially solves the
problem by allowing dynamic linking of cmo's over NFS, but
dynamic linking over other network transport protocols would
be a real pain, requiring explicit downloading and temporary
storage. And finally, a mixed byte-native runtime is not
supported.

Anything we can do about this?

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