Re: Diversity - existence, value, and pursuit.

[Simon Cozens <address@hidden>]

On Sun, Dec 02, 2001 at 01:03:43PM -0500, Shriram Krishnamurthi wrote:
> Let me try to make my point again, politely.

Thank you. Let's go through this. :)

> Hence, it's critical to distinguish between an "interactive
> programming environment" and an "interpreter".  People used to the C
> world are conditioned to thinking an "interpreter" is something that
> consumes and evaluates an expression at a time.  But that's not what
> an interpreter is! 

Indeed; and I'd even go so far as to dispute the idea that C folk think
of an interpreter like that - shell folk, maybe. The fact is that very
few of the "interpreters" out there give you line-at-a-time execution -
not since the days of BASIC ROMs, at least. Perl, Python (and all the
others worth talking about ;-) compile the whole file to an internal
representation, then execute. You and I both know that interaction is
neither here nor there. (In fact, Perl has no interactive mode to speak
of, other than the debugger.)

So I think the important distinction is between (for want of a better
word) "interpreters" which use a virtual machine, and those which compile
either to native code via a JIT or through C. 

Maybe the problem is that I think of "interpreter" as something that
uses a VM - if it turns the code into another language, I'd call that a
compiler. Perhaps that's where our terminology dispute comes from.

I'm under the impression - and I would love to be proven wrong! - that
VMs give you a big win both in terms of portability and operating system
level abstraction. Your VM provides access to the operating system
services in a nice, generalised, portable way. To get the same sort of
abstraction from a code generator would be more tricky, I think. But on
other hand, it's obvious that you can't get code running on a VM to run
as fast as C.

On the gripping hand, you can turn a VM-based bytecode into C or
whatever your implementation language is relatively easily, by inlining
the code for the operations which the VM will execute. (The program
"pmc2c" in the Parrot CVS does this for Parrot.) This is obviously not
quite as good as writing a dedicated C program, since it's still
dependent on the services provided by the VM. 

Whether or not this turns out to be a win depends on how "fat" your VM
is - if there's a convoluted runtime that you need to link in and set
up, then it may end up being as slow or even slower. This is why the
Perl Compiler never really took off - you still need the interpreter
sitting around for all the dynamic-data stuff. So far, Parrot's VM is
very lightweight, and so we can see speedups of between 50 and 100 times
by unrolling the op despatch loop. I have a horrible feeling that'll
change as we require more from the VM.

The other biggy that I can never get my head around is how you'd
implement "eval" in any code-generation language. How do the compiled
Scheme implementations manage it, and what effect does this have on
portability?

-- 
"He was a modest, good-humored boy.  It was Oxford that made him
insufferable."