Browse thread
[Caml-list] Delaying module initialization
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jacques Garrigue <garrigue@k...> |
| Subject: | Re: [Caml-list] Delaying module initialization |
From: skaller <skaller@users.sourceforge.net> > > 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