Juice [Re: UVM and Microsoft]

[Michael Korns]

Dwight,

> After being quite excited about Juice, to the point of wanting
> to base the entire LispOS on such an approach (not just the LispVM)
> -- like they have done with Oberon -- I find myself rather 
> ambivalent about it upon further study. (Don't let this hinder
> your own research - Juice is truly fascinating and has a *lot* to
> offer to this project.)

I just got through looking at everything Juice has. I like it in ways
similar to your own. What I don't understand is how Juice differs from a
JIT? Suppose we send a compressed Lisp S-expression across the Web,
uncompress it at the destination and eval it. Assuming the eval compiles to
native before running, we have a Juice analogous JIT. Assuming the eval
compiles to VM pcodes and emulates, we have a Juice-Java hybrid? What am I
missing here?

> The aspects I do not like are: 
> 1) the compact AST intermediate representation cannot be efficiently
> interpreted, making porting between architectures rather a pain -
> native code or nothing basically (of course, we don't have to do it
> exactly this way)

I agree completely. See the above Juice-Java hybrid.

> 2) the native code generated is of rather poor quality (no fault
> of theirs - they have simply tuned for speed of generation, not
> optimization).

Their site claims execution speeds equal or better than Java JIT's. How do
we get a verification of their actual code execution speeds versus Java JIT
execution speeds?