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 MAA07101; Sun, 28 Mar 2004 12:34:54 +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 MAA07282 for ; Sun, 28 Mar 2004 12:34:53 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i2SAZQKW032228 for ; Sun, 28 Mar 2004 12:35:27 +0200 Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2-20030924/3.7W) with ESMTP id TAA28677; Sun, 28 Mar 2004 19:34:37 +0900 (JST) To: skaller@users.sourceforge.net Cc: caml-list@inria.fr Subject: Re: [Caml-list] Delaying module initialization In-Reply-To: <1080403497.4708.160.camel@pelican.wigram> References: <20040327121832.B29840@pauillac.inria.fr> <406575DA.2090908@socialtools.net> <1080403497.4708.160.camel@pelican.wigram> X-Mailer: Mew version 1.94.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20040328193438O.garrigue@kurims.kyoto-u.ac.jp> Date: Sun, 28 Mar 2004 19:34:38 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) 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 jacques:01 sourceforge:01 dynamically:01 dynamically:01 loadable:01 symmetry:01 jacques:01 caml:01 caml:01 stubs:01 bytecode:01 bytecode:01 garrigue:01 garrigue:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 397 From: skaller > > If Caml could make shared libraries, perhaps those sorts of > > libraries (very large libraries, meant to be used by many small > > programs) would have a better chance of being written in Caml. > > Yes. There is a tension between dynamically loading which is > possible with bytecode, and generation of dynamically loadable > native code. > > 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. I think this is a huge improvement. And if you're going to use .NET, shouldn't you be happy with bytecode :-) The main reason I see for wanting dynamic loading of native code is speed, and symmetry with bytecode. These are valid reasons. But for one I'm perfectly happy with bytecode. Jacques Garrigue ------------------- 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