Re: A Modest Proposal

[Noah Lavine]

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