On Wed, Aug 25, 2004 at 07:37:45PM +0200, Basile Starynkevitch [local] wrote:
> The substantial differences in the GC, and the lack of closure &
> tailcall support in JVM is a well known barrier against using the JVM
> for functional language implementations. In other words, even if some
> Java enthusiasts tell otherwise, the JVM is not the universal UNCOL of
> our time!

It's not really an issue of speed.  It's got a lot more to do with
compatibility.  For example, an implementation like Nicolas Cannasse's
which would allow you to run the Java bytecode in a "sandbox JVM",
while keeping the main OCaml code as OCaml bytecode or native code,
would be entirely acceptable for me.

Perl4caml works very similarly to this.  Even if your OCaml code is
native, when you call out to Perl, it runs in the Perl interpreter
(in-process).  This is sufficient to provide access to the Perl
libraries.  It's not particularly fast, but you only suffer a penalty
for the small portion of the program where you call out to Perl, and
the main thing is programmer productivity anyhow.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
PTHRLIB is a library for writing small, efficient and fast servers in C.
HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/