Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Alternative Bytecodes for OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-08-27 (20:56)
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, 

John Goerzen
Author, Foundations of Python Network Programming

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: