overriding built-ins

[Pettersen, Bjorn S]

> From: dan [mailto:danbmil99 at yahoo.com] 
> 
[...]
> 
> However that brings up an interesting issue: the plethora of new
> languages with bytecode interpreters (Java, Python, C#) are starting
> to concern me.  It seems like there could be a place for some sort of
> standardized, low-level bytecode syntax, so that work on things like
> JIC compilation can occur independently of high-level changes and
> alternatives to source syntax.
[...]

First the Python VM (PVM) is very different from the JVM, and CLR which
you mention. Both the JVM and the CLR use relatively low-level byte
codes while the PVM byte-codes are strongly tied to the Python language.
For just-in-time (JIT) compilation to be worth the effort you need
low-level byte codes (not entirely true, but close ;-). The Python byte
codes, implmented in highly optimized C, are hard to improve with a
simpleminded scheme.

That said, there's work on a new VM for Perl, Python, and probably other
VHLLs, http://www.python.org/parrot.html (I could give you the direct
link, but what fun would that be :-)

The JVM has been targetted by many research projects, probably best
known is the Pizza language/java-superset:
http://pizzacompiler.sourceforge.net/. 

The CLR, which is compiled before execution (i.e. strictly speaking C#
doesn't use a bytecode interpreter :-), is of course trying to be all
things to all people but has been struggeling with a primitive type
system. Work has been done to add F-bounded parametric polymorphism
(think c++ templates with [interface] constraints on the template
arguments [much simplified]).  An interesting paper is:
http://research.microsoft.com/projects/clrgen/generics.pdf.

Dynamic recompilation can augment VM execution, e.g.:
http://www.cs.ucsb.edu/labs/oocsb/papers/pldi94.pdf

VHLLs _can_ of course be compiled directly to machine code, the Vortex
compiler of the Cecil project used to have a SmallTalk front end
(http://www.cs.washington.edu/research/projects/cecil/www/Release/).

For an interesting approach, there is domain specific VM generation,
where the compiler emits a higlhy specialized VM 'dialect' for the
program at hand
(http://www.usenix.org/publications/library/proceedings/javavm02/full_pa
pers/venugopal/venugopal_html/).

Theoretically, the best combination of speed and flexibility can be
achived by specializing compilers, like e.g. Psyco
(http://psyco.sourceforge.net/).

As you can see, there is no real consensus on what the best approach is,
or even if there is one. While the Cecil approach sounds like what
"everyone" wants, the tradeoff is hours of compilation time... For now
it's probably good to have a plethora of VMs.

-- bjorn