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] |
> 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