Re: [Caml-list] Alternative Bytecodes for OCaml

[John Goerzen <jgoerzen@complete.org>]

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