This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Guile & PR


> Of course it is necessary to restrict to true interpreters, for its
> unfair otherwise. Bytecode or native code are intented to optimize
> performance at the cost of extra stages of compilation.

But restricting to only certain implementation techniques is also
unfair.  The key is not if there are extra stages of compilation;
the key is the response time.  Kawa is as responsive as a true
interpreter:  It provides eval, load, a repl, yet it compiles
directly to bytecode without writing any temporary files or
invoking external programs.  (I'm not saying Kawa is unique in
this - except for other Java-based systems.  I believe Scheme48
and RScheme do the same, but using their own bytecode format.)

A more reasonable restriction might be in terms of resources
needed - such as how much space does a bytecode-based system need.
For modern desktop systems that is no longer an important issue,
but it is of course very important for embedded systems, for example.

> Does that depend on the Java virtual machine? (jdk, kaffe, ...) ?

Yes.  I have mostly worked with JDK1.1.x.

> While being at kawa, I have seen a new free partial clone of Sun's
> java standard library announced on the gnu software page. Will that
> one be tested with kawa, too?

If you are talking about Classpath, that is not a complete Java
system - it does not include an interpreter, only libraries
intended to be used *with* some free interpreter.

What I have done so far is compile of Kawa using Gcj, our
gcc-based Java compiler+library.  It runs, but since Gcj does
not include an interpreter yet, it can only evaluate simple
expressions (basically ones that don't involve lambda).
What it could do (but I haven't tried it) is compile Scheme
to bytecode, and then to native code, which could be linked
with libKawa.  This gives us Scheme compiled to native code.
I will work on this once libGcj is released to the Net (which
finally seems like it will happen very soon).

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner