From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA05870; Wed, 2 Oct 2002 14:55:00 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA05788 for ; Wed, 2 Oct 2002 14:54:59 +0200 (MET DST) Received: from athlon.baretta.com (host57-68.pool80116.interbusiness.it [80.116.68.57]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g92Csw525146 for ; Wed, 2 Oct 2002 14:54:58 +0200 (MET DST) Received: from baretta.com (localhost.localdomain [127.0.0.1]) by athlon.baretta.com (Postfix) with ESMTP id 8CBBE2739E for ; Wed, 2 Oct 2002 15:04:48 +0200 (CEST) Message-ID: <3D9AEEF0.4000706@baretta.com> Date: Wed, 02 Oct 2002 15:04:48 +0200 From: Alessandro Baretta Organization: Baretta srl -- www.baretta.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: it, en MIME-Version: 1.0 To: Ocaml Subject: Re: [Caml-list] choosing modules at runtime References: <8D1414482878D4119AEE00508B6C9074089664C9@seacex02.eib.electrabel.be> <20020924114123.GC7700@fichte.ai.univie.ac.at> <3D97FD0C.4020205@ozemail.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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