Re: The compilation approach in modern languages

glen herrmannsfeldt <gah@ugcs.caltech.edu>
13 Feb 2005 23:41:01 -0500

          From comp.compilers

Related articles
The compilation approach in modern languages sgganesh@gmail.com (Ganny) (2005-02-11)
Re: The compilation approach in modern languages rbates@southwind.net (Rodney M. Bates) (2005-02-12)
Re: The compilation approach in modern languages sgganesh@gmail.com (Ganny) (2005-02-12)
Re: The compilation approach in modern languages bobduff@shell01.TheWorld.com (Robert A Duff) (2005-02-13)
Re: The compilation approach in modern languages cartazio@gmail.com (Carter Schonwald) (2005-02-13)
Re: The compilation approach in modern languages dot@dotat.at (Tony Finch) (2005-02-13)
Re: The compilation approach in modern languages gah@ugcs.caltech.edu (glen herrmannsfeldt) (2005-02-13)
Re: The compilation approach in modern languages nmm1@cus.cam.ac.uk (2005-02-16)
Re: The compilation approach in modern languages boldyrev@cgitftp.uiggm.nsc.ru (Ivan Boldyrev) (2005-02-16)
Re: The compilation approach in modern languages boldyrev+nospam@cgitftp.uiggm.nsc.ru (Ivan Boldyrev) (2005-02-16)
Re: The compilation approach in modern languages rbates@southwind.net (Rodney M. Bates) (2005-02-16)
Re: The compilation approach in modern languages gneuner2@comcast.net (George Neuner) (2005-02-16)
Re: The compilation approach in modern languages torbenm@diku.dk (2005-02-18)
[10 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: 13 Feb 2005 23:41:01 -0500
Organization: Compilers Central
References: 05-02-053 05-02-056
Keywords: interpreter, design
X-ASG-Orig-Subj: 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]



Post a followup to this message

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