castironpi <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
