[Caml-list] [ANN] OCaml-Java project: 1.0 release
fo...@x9c.fr
The goal of the OCaml-Java project is to allow seamless integration of
OCaml and Java.
Home page: http://ocamljava.x9c.fr
This version features a new source distribution which includes the
standard distribution
of Objective Caml 3.10.2, and all the libraries needed to build the
whole OCaml-Java project.
URL: http://ocamljava.x9c.fr/downloads.html
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
distribution.
So far, this distribution has been tested on two platforms: MacOS X.5
(32-bit),
and Fedora 8 (64-bit). I will be thankful to developers reporting
success or
failure on other platforms.
Xavier Clerc
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Jon Harrop
> This post announces the 1.0 release of the OCaml-Java project.
> The goal of the OCaml-Java project is to allow seamless integration of
> OCaml and Java.
> Home page: http://ocamljava.x9c.fr
>
> This version features a new source distribution which includes the
> standard distribution
> of Objective Caml 3.10.2, and all the libraries needed to build the
> whole OCaml-Java project.
> URL: http://ocamljava.x9c.fr/downloads.html
>
> 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
> distribution.
> So far, this distribution has been tested on two platforms: MacOS X.5
> (32-bit),
> and Fedora 8 (64-bit). I will be thankful to developers reporting
> success or
> failure on other platforms.
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
JVM?
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.
http://www.ffconsultancy.com/products/?e
Till Varoquaux
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)
Till
>
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/products/?e
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
--
http://till-varoquaux.blogspot.com/
Jon Harrop
> On Tue, May 27, 2008 at 7:06 AM, Jon Harrop <j...@ffconsultancy.com> 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)
What characteristics of tail calls cannot be implemented using trampolines?
fo...@x9c.fr
> 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
> JVM?
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
correctly).
> 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
languages.
> 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,
Xavier Clerc
fo...@x9c.fr
> 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 ?
Xavier Clerc
Till Varoquaux
> On Tuesday 27 May 2008 07:37:40 Till Varoquaux wrote:
>> On Tue, May 27, 2008 at 7:06 AM, Jon Harrop <j...@ffconsultancy.com> 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)
>
> What characteristics of tail calls cannot be implemented using trampolines?
>
I am sure you are aware of this but trampolining is very expensive
[1]. 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 [2]
Till
[1] Tail call elimination on the Java Virtual Machine
[2] CONS Should Not CONS Its Arguments, Part II: Cheney on the M.T.A.
> --
> Dr Jon D Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/products/?e
>
Tail call elimination on the Java Virtual Machine
--
http://till-varoquaux.blogspot.com/
Till Varoquaux
have a bad case of dyslexia today and my previous mails are written in
horrible english...
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."
Trampolines tend to have a very high runtime cost. You have to think
very carefully about the tradeoffs when converting a whole program to
using them.
HTH,
Till
--
http://till-varoquaux.blogspot.com/
Richard Jones
> Well, Richard Jones provided a Fedora package for alpha/beta.
This is our tracker for ocamljava:
https://bugzilla.redhat.com/show_bug.cgi?id=434560
I probably won't get around to updating this package to 1.0 this week.
Rich.
--
Richard Jones
Red Hat
Florian Weimer
> 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).
fo...@x9c.fr
Le 27 mai 08 à 19:59, Florian Weimer a écrit :
> * Till Varoquaux:
>
>> 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
"trampoline"
(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
of very-late
linking as proposed by Java.
Xavier Clerc