This version features a new source distribution which includes the
of Objective Caml 3.10.2, and all the libraries needed to build the
whole OCaml-Java project.
Main changes since beta:
- source distribution
- support for OCaml 3.10.2
- support for camlp4
- better handling of Java errors
- ocamllex, ocamldoc, and ocamldep added to the binary distribution
- bug fixes
I am still looking for testers, particularly concerning the source
So far, this distribution has been tested on two platforms: MacOS X.5
and Fedora 8 (64-bit). I will be thankful to developers reporting
failure on other platforms.
Caml-list mailing list. Subscription management:
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
I would love to test this but I do have some questions:
1. Do threads run in parallel, i.e. does it leverage the concurrent GC in the
2. What is the performance like?
3. Is anyone working on Debian packages for OCamlJava?
4. Are tail calls fully implemented and, if not, when exactly do they work?
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> Caml-list mailing list. Subscription management:
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
What characteristics of tail calls cannot be implemented using trampolines?
> On Tuesday 27 May 2008 06:46:23 fo...@x9c.fr wrote:
> I would love to test this but I do have some questions:
> 1. Do threads run in parallel, i.e. does it leverage the concurrent GC in the
No. This is in fact not possible as some parts of the OCaml runtime work only
under the assumption that there is only one thread in the runtime at once.
However, as soon as this assumption is lifted it will be possible to use
the concurrent GC of the JVM (the OCaml summer of code is supposed to deliver
such a patch to be integrated in the official Caml distribution if I remember
> 2. What is the performance like?
As of today, performance is not good. My objective for the 1.x branch is to
work on compatibility with the original implementation. Performance issues
are postponed to the 2.x branch. In the meantime, OCaml-Java has proved fast
enough to program lightweight GUI applications. Moreover, the very early (and
unconclusive) tests I run seem to show that it compete with so-called script
> 3. Is anyone working on Debian packages for OCamlJava?
Well, Richard Jones provided a Fedora package for alpha/beta.
It should not be very hard to adapt to 1.0 final, or to Debian.
> 4. Are tail calls fully implemented and, if not, when exactly do they work?
Tail calls are fully implemented for direct recursion, but not for calls to
other functions (it is not possible to "jump" out of a method in Java).
Thank you for your interest,
> On Tue, May 27, 2008 at 7:06 AM, Jon Harrop <j...@ffconsultancy.com> wrote:
> > On Tuesday 27 May 2008 06:46:23 fo...@x9c.fr wrote:
> > 4. Are tail calls fully implemented and, if not, when exactly do they work?
> One cannot fully implement tail calls on the JVM: there's no such
> thing as a goto or a tail call instruction.
> Tail recursion can usually be done for cheap. The general requires
> some expensive machinery (usually trampolines)
Well, to be precise the JVM provides a "goto" instruction, albeit limited
to offsets in the same method. This allows to easily implement tail calls
for direct recursion (and this is done in OCaml-Java).
Can you explain what you mean by "trampoline" in the Java/JVM context ?
I am sure you are aware of this but trampolining is very expensive
. A common trick to avoid using to much trampolining is to compile
the whole program in cps form (therefor all calls are tail calls) and
unwind the whole stack when we are about to overflow 
 Tail call elimination on the Java Virtual Machine
 CONS Should Not CONS Its Arguments, Part II: Cheney on the M.T.A.
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Tail call elimination on the Java Virtual Machine
Anyways; here goes for trampolines (straight from wikipedia):
"Used in some LISP implementations, a trampoline is a loop that
iteratively invokes thunk-returning functions. A single trampoline is
sufficient to express all control transfers of a program; a program so
expressed is trampolined or in "trampolined style"; converting a
program to trampolined style is trampolining. Trampolined functions
can be used to implement tail recursive function calls in
Trampolines tend to have a very high runtime cost. You have to think
very carefully about the tradeoffs when converting a whole program to
This is our tracker for ocamljava:
I probably won't get around to updating this package to 1.0 this week.
> Anyways; here goes for trampolines (straight from wikipedia):
> "Used in some LISP implementations, a trampoline is a loop that
> iteratively invokes thunk-returning functions. A single trampoline is
> sufficient to express all control transfers of a program; a program so
> expressed is trampolined or in "trampolined style"; converting a
> program to trampolined style is trampolining. Trampolined functions
> can be used to implement tail recursive function calls in
> stack-oriented languages."
I'm not sure if this is this a universally understood term. In GHC
land, this is called a "mini-interpreter". The mini-interpreter doesn't
have to be *that* expensive if you can avoid consing, but this seems to
require whole-program analysis (or, at the very least, rather powerful
inter-procedural escape analysis).
I think I've heard this term mostly in the context of currying
(specifically, in the implementation of downward closures in languages
such as Ada).
Indeed, I was aware of such a technique but did not know the name
(quite funny, by the way). It is highly improbable that I will
implement this in
OCaml-Java. I want to keep separate compilation, and the possibility
linking as proposed by Java.