Re: librep's indirect threaded bytecode interpretter

[Per Bothner <per at bothner dot com>]

Miroslav Silovic <silovic@zesoi.fer.hr> writes:

> Actually there is VERY simple practical issue about JVM: its FFI is
> quite different from Guile's, which makes its use completely academic,
> at least in my case - there's no bloody way I'd bother porting my
> extension libs to JVM (when SCM is still available).

This is certainly a valid concern.  But I don't think there is any
inherent reason why there can't be a set of wrappers to support the
existing Guile C API.  Such a wrapper may be inefficient when
implemented using the port Java Native Interface.  However, if
we supply a "Guile-JVM" as I mentioned earlier, then it should be
straight-forward to write simple and efficient wrappers.  If you
use libgcj (the runtime for gcj) then I think it should also be
easy.  The main obvious difference is that a Java-based Guile
would (probably) not have "immediate values" - instead all Scheme
values are pointers.  (Small integers are pre-allocated.)

I'd like to emphasize:  A version of Guile that uses Java bytecodes
need not be restricted to something that is portable and runs on
all Java VMs.  I don't think Guile extensions written in C need
to be 100% portable to all Java implementations.  (Guile
applications written in portable Scheme that do not depend
on non-portable libraries, tail-calls, or call/cc should
however, be portable to all Java implementations.)

Here is a cook-book for how one might merge Guile and Kawa,
that is based on the concept of starting from Guile and
preserving Guile functionality, while moving towards using
Java objects and the Kawa compiler.  (One could of course start
from Kawa and add Guile features instead.)

* Add a free Java interpreter (probably libgcj or Kaffe) to Guile, so
they can co-exist in the same application, but not much more.
* Change Guile so Java object references can be used as Scheme
values.  I.e. Java object references can be components of Scheme
lists.  This may be more work that appears obvious.  For example,
there may be garbage collection problems.  So to begin with it
may make sense to start with a lesser goal:  Define a smob that
can contain a pointer to a Java object.  Conversely, define a
Java class that contains a SCM value.
* Define a Guile smob for wrapping Kawa Procedure objects *and*
a Kawa Procedure class that contains a pointer to a Guile
procedure, and calls the Guile evaluator.  The goal is to be
able to mix Guile and Kawa procedures during the transition phase.
* For each non-immeditate Guile type, change the representation
so it uses a Java type (perhaps indirected via a smob).  Use
the same Java class that Kawa uses.  You can still use the
existing Guile primitive functions for manipulating the type.
* For immediate Guile types, change the representation to use
the non-immediate class that Kawa uses.
* When all the Guile types have been changed to use Java objects,
change over to use the Java garbage collector in place of the
Guile one.  (libgcj uses the Boehm conservative collector.)
* Replace Guile data-manipulation procedures by corresponding
Kawa procedures.
* Change eval to call the Kawa version of eval.
* Throw away the Guile reader and evaluator and other
no-longer-needed code.
* Any Guile features that you want to be portable to all JVMs
should be re-written in Java.  In many cases, you can use the
Kawa implementation, possibly with a Guile compatibility wrapper.

(If somebody goes about doing this, I'll be glad to assign my
Kawa code to the FSF.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/