LispVM

[Pierre De Pascale]

I think it is time to jump in the wagon,

I have just read all those messages concerning the definition of a
Lisp VM.

To add my 2 cents in this thread I think the views of Fare Rideau are
right. The Lisp VM should be a high level VM, not something resembling
a portable, geared towards Lisp/Scheme assembly language. There are
reasons against this kind of design:

- those kind of assembly isn't general enough for all kind of
hardware. Of course it will always be POSSIBLE to run this VM on all
kind of hardware, but we achieve better efficency with a high level
VM.

- we are then stuck with one VM and integrating changes or new version
may be difficult, clumsy and may require redesign or hacks.

There are better alternatives in my point of view. 

High level VM have already been used in at least two projects: Oberon
and one in the UK. Both project achieve portability good: a program
compiled on one Oberon system (let say on a PC) can be directly used
on another Oberon system on a Mac. But the biggest advantage is that
compilation can be done EFFICIENTLY on different hardware because you
keep more information of the source language, thus allowing greater
optimization.

The size of object files are not necessarily bigger than native object
files and can even be smaller.

With a high level VM it is always possible to compile it to a standard
VM like Java VM or UVM or whatever.

It is easier to track security because you have a high level
description of your application (it is easier to see, for example,
that a program is well typed in a high level language than from
assembly). 

My current view for a Lisp VM is a kind of lambda calculi
description. This kind of description should accomodate Lisp/Scheme/ML
and even non-strict functional language like Haskell. Thus ending a
language war like: "No I want a LispOS written in XXX" where XXX is
Lisp or Scheme or ML. You simply provide translator from XXX to Lisp
VM.

In traditionnal compilation of Scheme/ML (Lisp can too, but I have no
reference on compiling Lisp), the source language is always translated
in some sort of lambda-calcul language. Well you "desugar" your language
allowing only lambda, letrec, if, constant creation and variable
reference. Then you REALLY compile this language into assembly or a
low level assembly language. Thus why not using this language as a VM.

The Bigloo compiler already compiles Scheme and CAML (an ML dialect)
pretty efficiently. Thus showing the feasability of such a system.

I think we definitly should incorporate the ideas of OBERON, TUNES and
BIGLOO in the Lisp OS.

I know this kind of high level VM is different from what has been done
in the long tradition of VM design, but we have everything to gain
from such design.

For the Smalltalk people I currently do not see how we can intergrate
EFFICIENTLY such language in a Lisp/Scheme/ML framework. Maybe others
?

Finally I am willing to give some of my time to develop such OS. You
can count me in. I can work on the compiler, OS side and even anything
else that could help to bring to reality this project.

Greetings from Switzerland,

- Pierre. 
  dpa@siemens.ch

PS: I can provide references if anyone is interested.