Embedding VMs

[Paul Prescod]

Marc Wachowitz wrote:
> The only way to extend the JVM is via imlementation defined attributes
> (look what even Sun had to do for nested classes in Java 1.1), which
> I'd consider a harmful approach for LispOS - it's just too much garbage
> which would have to show up throughout the system.

Sun's goal was to allow the NEW bytecodes to work in OLD JVM
implementations. If you don't care about that, you can just create new
bytecodes. Anyhow, I would argue for the implementation defined
attributes. Per Bothner also seemed to support this route the last time
I talked to him. He didn't see the limitations of the JVM as being a
very big impediment to Kawa's performance. 

> On the other hand, if all you need is the ability to execute arbitrary
> class files in JVM format, the user won't be able to tell whether LispOS
> uses JVM for itself or just translates it (on load time or in advance).
> Remember, a virtual machine is just _one_interface_, and tells _nothing_
> about the way it's really implemented, or which other interfaces may
> be supported by the implementation, any more than you could tell whether
> some WWW browser was written in Pascal, C, Fortran, Prolog, APL, Lisp,
> x86 assembly, or whatever else.

What you are describing is a system which is backwards compatible with
the JVM: an extended JVM. I believe that starting from existing JVM
source is much more efficient than starting from scratch, and that using
attributes to remain compatible with existing JVMs would be a good idea.
 
> Can you tell us some _technical_ reason for using JVM anywhere else than
> in a class loader for JVM code? 

I think that the technical reason for using the JVM is that there are
millions of JVMs deployed and thousands more every day. If we develop
technology that is compatible with that user base then we can easily
deploy it and easily deploy technology based upon it. The "risk" in
moving to Lisp-Environment would be minimal because all of the old
software would keep working and the new software would be as readily
deployable as software written in Java or C++.

> If you merely want to do so for marketing
> hype, I doubt you'll find much support for that around here. That approach
> does just about everything wrong for a LispOS developed as free software
> and intended to evolve.

I think that the thread that started this whole idea was: "why is TCL so
bloody popular when Lisp, which is much better, is not?" I think the
answer has everything to do with Lisp people trying to reinvent the
perfect wheel rather than using the capable but imperfect ones laying
around. There are hundreds of theoretically perfect operating systems
sitting in labs collecting binary dust. Why develop another one?? 

What I want from "LispOS" or "LispEnv" (or whatever) is to be able to
develop applications in Lisp, in a nice Lisp-smart development
environment, have access to powerful, plentiful libraries that deal in
objects and lists rather than strings and pointers and then deploy my
apps on Windows, Unix and the Mac. Why write an OS from scratch?

 Paul Prescod