Re: The compilation approach in modern languages

Rodney M. Bates wrote:


> It is a common misconception that certain languages are "interpreted"
> and others are "compiled" In fact, the distinction between compiled
> and interpreted (and hybrids) is not a property of the language, but
> only of the implementation.


> We now have a traditional native code compiler for Java. There were
> hybrid translator/interpreter implementations for C around 15 years
> ago.


> The one exception is the functional languages, where functions can be,
> in effect, manipulated at runtime and then evaluated. Obviously, it
> is too late then for a traditional batch compile, and something more
> like interpretation is needed, at least some of the time.


There are also macro languages like TeX which can't be compiled for
similar reasons. For TeX, even that category codes for characters
(letter, etc.) can be changed dynamically, so the rules on processing
characters must be followed exactly.


Also, at least according to CS people I talk to, most systems are
somewhere between true compilers and true interpreters.


Most interpreters for programming languages (as opposed to command
processors) compile to an intermediate form, possibly just converting
language keyword tokens to an internal form, sometimes also including
converting numerical constants to internal form.


Most compiled languages generate code including calls to a library,
instead of generating all code inline, as a true compiler should.
Even more obvious, interpretation of format strings for formatted I/O.


-- glen
[You might be surprised what PL/I compilers do with format strings.
I've seen them compiled to thunk-like things that run as coroutines
with the part of the program doing the I/O. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.