[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Diversity - existence, value, and pursuit.
Date: Sun, 2 Dec 2001 13:03:43 -0500 (EST)
From: Shriram Krishnamurthi <sk@cs.brown.edu>
There are several honest-to-goodness Scheme *compilers* out in the
world.
And just to round out your point, there is (there used to be) an
honest-to-goodness C interpreter, from Saber Software (later
Centerline, Sesha Pratap's company). It had a lot of the sort of
features that someone from the Lisp world might expect; I am pretty
sure it had a REPL, or the closest thing to such a thing possible for
C.
Some systems, in fact, have both an interpreter and a compiler, and
examine the size and nature of the actual expression to decide whether
it would be quicker to just run it in the interpreter (no time wasted
on code generation and scaffold erection) or to generate machine code
and execute that by jumping to it. You'd be darned if you could tell
whether the interpreter or the compiler was running at a given instant.
That sounds to me very close to a description of of the "JIT compiler"
strategy used by many Java implementations, including the Sun Java
implementation.
So the lanauage is separate from the implementation. And then there's
the topic of interpreted versus compiled implementations:
Date: Sun, 2 Dec 2001 18:45:34 +0000
From: Simon Cozens <simon@simon-cozens.org>
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.
Yes, informally I would probably say the same thing. But when you try
to get more careful (formal) about the distinction, how do you
distinguish between a "virtual machine" and "native code"? What if
the code is "native" but the actual CPU uses microprogramming? What if
someone makes a chip that executes the "virtual machine" bytecodes "in
hardware"?
Actually I don't think there's any way to make a "bright line"
distinction between a "compiled implementation" and an "interpreted
implementation" of a lanauage, and very few serious implementations of
any language can claim to be purely one or purely the other. Very few
serious "interpreted" implementations don't in some way pre-parse or
pre-process their textual representation in some way. Very few
"compiled" implementations don't ever generate code that calls into
runtime libraries of some sort. (And this isn't a new point; this is
what I was taught in the first day of my undergraduate "compilers"
course at MIT circa 1976).