Browse thread
[Caml-list] Alternative Bytecodes for OCaml
[
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: | John Goerzen <jgoerzen@c...> |
| Subject: | Re: [Caml-list] Alternative Bytecodes for OCaml |
On Friday 27 August 2004 03:39 pm, skaller wrote: > On Sat, 2004-08-28 at 04:49, John Goerzen wrote: > > On Friday 27 August 2004 01:37 pm, skaller wrote: > > > The way to get a library of important utilities > > > for Ocaml is to (a) make interfaces to C and (b) write the code > > > in Ocaml. > > > > Why is C so much better? It's actually pretty darn difficult to > > interface to C from a higher-level language. > > Two reasons. One: C is the portable interface > to almost all operating systems -- there are This means that you could write an OCaml interface to syscalls. Granted, that's an advantage, but one I rarely need. > Two: there are a lot of libraries written > in C with C interfaces, which are either > compliant with some standard or open source. That's true. At the same time, binding to C is just about the most difficult language I could imagine to bind to. There are all sorts of issues to consider. Pointers cause trouble all over the place -- is this bit of data allocated, returned from a static place in a function, a global variable that never should be freed? Is this variable input, output, or both? When do I allow the memory to be freed? What if the C side is using garbage collection too? How do I represent this union in OCaml? Now, I've written plenty of C code. It's tough enough to use several libraries in a pure-C project, let alone with other languages. > In particular most programming languages, > such as Python, have C level APIs. True, though most are also getting .NET CLI-level APIs these days. > So binding to C does really have a particular importance. > Ocaml already has reasonable facilities to do it > (including documentation) I'm not disputing that at all. Obviously this is true. I'm just suggesting that other approaches have utility, too, because they're superior in some situations. > > And (b) is sometimes just NOT an option, either because of time > > constraints or because you don't know what the original code does > > to start with. > > I agree. But an off-the-shelf guarranteed interface to > Java isn't currently available either. Where should you > put your energy? > > > That's way too easy: JDBC. (Not because OcamlDBI sucks but because > > so many databases have JDBC available.) > > Surely enhancing OcamlDBI is a viable option? I have to talk to several databases who provide drivers only for Windows ODBC and Java JDBC. There is no hope of OCamlDBI supporting them, ever. -- John Goerzen Author, Foundations of Python Network Programming http://www.complete.org/pynet ------------------- 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