interpreter vs. compiled

[Tim Roberts]

castironpi <castironpi at gmail.com> wrote:
>
>And furthermore, I think I'm getting
>confused about what exactly constitutes an interpreter: it is whether
>there is a process that runs product instructions, or the product
>instructions can run standalone.  I would take 'compiler' to mean,
>something that outputs an .EXE executable binary file, and I don't
>just mean bundling up the python.exe executable with a file.

OK, let me give MY definition.  I freely grant that my definition might be
different from anyone elses, but perhaps this will help you understand the
basis for my arguments.

If I run three different CPython programs, the bytes of machine language
that get executed are come from the same place: python24.dll.  My user
programs are just data.  That, in my mind, makes the CPython implementation
an interpreter.

If I compile and run three different C programs, the bytes of machine
language will be come from three different places.  That, in my mind, makes
my C implementation a compiler.

If I compile and run three different C# programs, the JIT compiler makes
new machine language for each one.  The bytes of machine language will come
from three different places.  That, in my mind, makes the C# implementation
a compiler.

If I compile and run three different IronPython programs, the JIT compiler
makes new machine language for each one.  The bytes of machine language
will come from three different places.  That, in my mind, makes the
IronPython implementation a compiler.

All four of those scenarios require run-time library support.  Even the C
progam does not run on its own.  Execution starts in the run-time library,
which sets up an environment before jumping to "main".  The C# and
IronPython situations are the same; it's just that there's more processing
going on before jumping to "main".
-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.