Hello, > I think we should first compare the virtual machines. > > > If no obvious impossibility is observed, then perhaps modifying the > compiler of clisp to generate guile VM code would be an easy path to > obtain a CL implementation running on guile VM. (This would disable the > interpreter in clisp, since it is implemented in C). > > Or, vice-versa, if the VM of clisp has advantages (but if guile has > continuations, this would be lacking in the clisp VM). > > > > In general, there may be a need for a very good lisp virtual machine to > run and integrate lisp code in general (CL, various schemes, and other > sorts of lisp-like languages, we could include perhaps implementations > of python, ruby, smalltalk, javascript, etc). From well afar, it > looks like the JVM is not good enough for lisp (ABCL, Clojure, seem to > have some difficulties to implement some basic lisp features on the > JVM).
I think what you're saying may be good, but I'm very hesitant to move ahead without lots of people agreeing. I would be very afraid that we would have friction as two groups of people who hadn't known each other previously tried to work together. For instance, what if some of us want to move the VM in one direction and others in another direction? Or what if the groups have different standards for when we make changes to the VM? On the other hand, there could be significant advantages. I see two big ones: first, that interoperability means that when one of us scratches an itch, all of us benefit, and second, that users of embedded interpreters would have to learn less. If the GNU project has only one embedded interpreter, then once you know how to use that, you can modify all GNU programs. So I think it might be good in the end if we all worked together, but I think it is a rather big step. What do other people think? Finally, to answer a few or your concrete points: > This VGLVM would: > > - be embeddable in applications, > > - include a FFI to native code, > > - be more performant than the JVM, > > - be natively multithreaded, > > - have a good real-time multithreaded garbage collector, > > - possibly have a JIT and/or a retargetting compiler, > > - allow easy (FFI-less) communication between the different languages > targetting it (for example, when we run pseudo, we can call CL > function from scheme and scheme functions from CL).. Guile already has 1, 2, and 4, and we are planning both parts of 6 for the near future. I think 7 would come automatically for languages that shared a VM. 3 and 5 I don't know anything about. It's also worth noting that Guile is already set up to compile multiple languages to its VM, so if we decide to go that route, some of the infrastructure is already there. Noah