|The compilation approach in modern languages firstname.lastname@example.org (Ganny) (2005-02-11)|
|Re: The compilation approach in modern languages email@example.com (Rodney M. Bates) (2005-02-12)|
|Re: The compilation approach in modern languages firstname.lastname@example.org (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 email@example.com (Carter Schonwald) (2005-02-13)|
|Re: The compilation approach in modern languages firstname.lastname@example.org (Tony Finch) (2005-02-13)|
|Re: The compilation approach in modern languages email@example.com (glen herrmannsfeldt) (2005-02-13)|
|Re: The compilation approach in modern languages firstname.lastname@example.org (2005-02-16)|
|Re: The compilation approach in modern languages email@example.com (Ivan Boldyrev) (2005-02-16)|
|Re: The compilation approach in modern languages firstname.lastname@example.org (Ivan Boldyrev) (2005-02-16)|
|[13 later articles]|
|From:||Robert A Duff <bobduff@shell01.TheWorld.com>|
|Date:||13 Feb 2005 22:45:21 -0500|
|Organization:||The World Public Access UNIX, Brookline, MA|
|Posted-Date:||13 Feb 2005 22:45:21 EST|
"Rodney M. Bates" <email@example.com> writes:
> 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.
True. But it is reasonable to ask what is typical, or what a
particular language designer intended.
Writing a native code generator for a language like one of the the
Unix shells (sh, csh, etc) would be a rather pointless exercise. I'd
say it's reasonable to call 'csh' an interpreted language, even though
in theory one could write a compiler for it. Same for the language of
DOS/Windows .bat files.
> We now have a traditional native code compiler for Java. There were
> hybrid translator/interpreter implementations for C around 15 years
> 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
Lots of non-functional languages have this property, too. Some
languages have the ability to calculate a text string at run time, and
then execute (interpret?) that string as a piece of program text. If
this is implemented by generating machine code (at run time) and then
executing the machine code, I'd call that "compiling", not
Java has the ability to load byte codes at run time. I'd call a JIT
compiler a "compiler", even though it's not a "traditional batch
> Ganny wrote:
> > What are the new languages that can possibly become mainstream
> > programming languages in academia/industry, and what is the
> > compilation technology they follow?
Writing an interpreter is a lot easier than writing a compiler, so I
suspect that most languages at least start out that way. Well, not a
"pure" interpreter, but a translator to something like byte codes,
which are then interpreted.
>> The arrival of Java bought the use of sophisticaed runtimes VM to
>> the mainstream (compared to the C/C++ native code approach). Does
>> most of the newer languages follow the similar approach, or most of
>> them follow the conventional approach of native code generation?
[I've seen Unix shell compilers, but I got the impression that the goal
was more to keep people from seeing what they did than to make them run
Return to the
Search the comp.compilers archives again.