Re: A Modest Proposal

[Pascal J. Bourguignon]

Noah Lavine <address@hidden> writes:

> Hello Guile and Clisp developers,
>
> I'm writing to talk about vague big-picture ideas, but please bear
> with me for a minute, because I think this could be useful.
>
> I noticed in the recent GNU Summer of Code applications (I'm a mentor
> for Guile) that CLisp wants to become embeddable, and embed into Emacs
> as a first test case. That would make Clisp an embeddable Lisp
> implementation with a bytecode-interpreting virtual machine, compiler,
> interpreter, debugger, etc. A very cool thing. Clisp developers might
> not be aware that that is exactly what GNU Guile is - a
> bytecode-interpreting virtual machine with a compiler, interpreter,
> debugger, and collection of useful tools. Guile is already embeddable,
> because that was one of Guile's original goals, but the difference is
> not so big. Guile also has a summer of code projects to embed itself
> into Emacs, in fact.
>
> It seems to me that it is time for Guile and CLisp to consider working
> together, because if we don't work together then I think we're both
> going to do the same work twice, separately.
>
> This depends greatly on what CLisp's goals are as a project, and I do
> not know those. Maybe you have very different goals than Guile, in
> which case we might not gain anything by working together. But I do
> have a feeling that we are both evolving towards the same place, and
> if so, I think it would be nice to cooperate some along the way.


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).


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)..



-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.