Prev: ANNOUNCE: Evex 0.50, Evaluation Expression for and in Ada
Next: GPS and assembly language files
From: Ludovic Brenta on 29 Mar 2010 16:06
I do not think any language can be said to be "interpreted" or
"compiled". Instead, any *implementation* of any language can be
"interpreted", "compiled" or something in between. It is almost a
continuum.

Interpreted, stricto sensu, means that the interpreter reads the sources
of the program as written by the human programmer.

In between: byte-code compilers, P-Code.

Just-in-time compilers usually compile byte-code to native processor
code on the fly.

Compiled means that the hardware processors runs the program directly,
even if, inside the hardware, some additional transformations can take
place for efficiency.

Some implentations of BASIC are interpreted, others are compiled.

Some implementations of Lisp are interpreted (emacs lisp), others are
byte-compiled (also emacs lisp), others still are compiled (GNU Common
Lisp).

Some implementations of Java are byte-compiled (Sun Java compiler),
others still are compiled (GCC).

Even one implementation of Ada, Ada/Ed, was interpreted!

You get the drift.

--
Ludovic Brenta.
From: Warren on 29 Mar 2010 16:51
Ludovic Brenta expounded in news:87k4sunb9u.fsf_-_(a)ludovic-brenta.org:

> I do not think any language can be said to be "interpreted" or
> "compiled". Instead, any *implementation* of any language can be
> "interpreted", "compiled" or something in between. It is almost a
> continuum.

Under Unix, it is generally accepted that if a 3rd-party
(not o/s and not so-called executable) process is required,
it is known as the "interpreter".

Linux for example used to (probably still does) have the
ability to register the "interpreter". This was done with
the JVM. Once the JVM was registered, you could launch the
byte-code as if it were a native executable-- which is
obviously slight-of-hand, since there is the necessary
invoking of the "interpreter" as well (it is not purely
the o/s being used).

Now I only mention "this" particular view (as before) of an
interpreter for the very simple utilitarian reason that
once you realize that an interpreting "middleman" is
involved, it is very obvious (i.e. not surprising)
that it runs less efficiently than other native code
options.

Any other concept of "interpreter" in this discussion of
performance is less interesting in this context.

BTW, emulation leads to the same conclusion as
an interpreter, since it too is "interpreting", even if
one doesn't usually call it that.

> Interpreted, stricto sensu, means that the interpreter reads the
> sources of the program as written by the human programmer.

I should probably shutup, but you do know that many of
"those" interpreters also use an intermediate code in
memory. So just because they don't store it in a file
that way, doesn't make them any more special IMO.

> You get the drift.

Yep. Yep.

Warren
 | 
Pages: 1
Prev: ANNOUNCE: Evex 0.50, Evaluation Expression for and in Ada
Next: GPS and assembly language files