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-28 (09:35)
From: Marcin 'Qrczak' Kowalczyk <qrczak@k...>
Subject: Re: [Caml-list] Alternative Bytecodes for OCaml
W li¶cie z sob, 28-08-2004, godz. 10:25 +1000, skaller napisa³:

> > That's true.  At the same time, binding to C is just about the most 
> > difficult language I could imagine to bind to.  
> Yeah? Just try interfacing two diffent memory management
> systems -- eg Ocaml and JVM garbage collectors :)

This is easy, as long as you don't mind not collecting cross-language
object cycles. Of course you do such thing via C glue.

After the basic infrastructure of wrapping and unwrapping objects works,
you don't have to think about memory management of data processed by
each function separately. It's much easier to use a foreign library
written in such language than one written in C, because memory
management of a C library is informally described in documentation only.

In general, if both languages are dynamically typed, or if the library
caller is dynamically typed and the library provider supports
reflection, then you might not need any glue specific to a library.
A generic wrapper might be convenient enough.

Exceptions are also doable, in such a way that they are wrapped and
unwrapped automatically.

I haven't tried threads.

I haven't tried Scheme continuations. It's not clear how they should
look like in the other language.

Tail call optimization across languages is out of reach even if both
languages support efficient tail calls, because converting the result
(or just wrapping or unwrapping) prevents any cross-language calls from
being tail calls.

I don't know if or when it's doable to tie garbage collectors such that
cross-language cycles are collected too. What hooks should they provide,
assuming both are mark & sweep or copying?

> And I'm not disputing that -- in general. I'm just questioning
> the utility of accessing inferior technology just
> to interface inferior libraries.

The libraries are not inferior even if they are written in an inferior

   __("<         Marcin Kowalczyk

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