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 BAA09760; Mon, 29 Mar 2004 01:51:15 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA10604 for ; Mon, 29 Mar 2004 01:51:14 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i2SNpqKW000429 for ; Mon, 29 Mar 2004 01:51:54 +0200 Received: from [192.168.1.200] (ppp113-158.lns1.syd3.internode.on.net [150.101.113.158]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i2SNp7wn067379; Mon, 29 Mar 2004 09:21:08 +0930 (CST) Subject: Re: [Caml-list] Delaying module initialization From: skaller Reply-To: skaller@users.sourceforge.net To: Jacques Garrigue Cc: skaller@users.sourceforge.net, caml-list In-Reply-To: <20040328193438O.garrigue@kurims.kyoto-u.ac.jp> References: <20040327121832.B29840@pauillac.inria.fr> <406575DA.2090908@socialtools.net> <1080403497.4708.160.camel@pelican.wigram> <20040328193438O.garrigue@kurims.kyoto-u.ac.jp> Content-Type: text/plain Message-Id: <1080517867.4708.174.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 29 Mar 2004 09:51:07 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 jacques:01 dynamically:01 dynamically:01 invokes:01 python:01 clumbsy:01 extensible:01 interscript:01 python:01 9660:01 glebe:01 gtk:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 400 On Sun, 2004-03-28 at 20:34, Jacques Garrigue wrote: > > The former is interesting but not industrially satisfying > > because it doesn't allow dynamic loading of interfaces > > to C, which must be native code. > > But, this is plain wrong: since 3.04 you can dynamically load C stubs > through dynamically loading a bytecode library. This I do not understanding but I seem to have missed something. Are you saying I can write a module X.ml which wraps a C library with function f(), and another Y.ml which wraps a different function f() of another shared library, and then write a program which can be run like: loadit X loadit Y where the first script invokes X's f() and the second Y's f()? That wasn't my understanding, but that is exactly what Python and Perl can do, and it's what is required. If you can do this you have a clumbsy way of generating code at run time and executing it, which is a fairly minimal condition for an extensible program. Interscript, for example, requires this facility (it uses the Python exec feature to do it one way, and importing of generated files as another). Another example which is less abstract: dynamically choose which version of GTK to run, meaning both the C shared library used *and* the wrapper code used are chosen at run time. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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