4 ms·

This article seems to be using a very specific definition of interpreter, which is perhaps not what most people think of when they hear "interpreter" ? If I un

This article seems to be using a very specific definition of interpreter, which is perhaps not what most people think of when they hear "interpreter" ? If I understand correctly, they call the module generating Python opcodes from Python code the "interpreter", and everything else is a "runtime". But Python opcodes are highly specific to CPython, and they are themselves interpreted, right? Calling the former "interpreter" and the latter something else seems like an artificial distinction. Not only is this definition of "interpreter" strange, but their definition of "runtime" also seems strange; in other languages, the runtime typically refers to code that assists in very specific operations (for example, garbage collection), not code that executes dynamically generated code.

tom_mellior 6y ago
> If I understand correctly, they call the module generating Python opcodes from Python code the "interpreter", No, you misunderstand. They explicitly define the interpreter as "ceval.c which evaluates and dispatches Python opcodes". Maybe "evaluate and dispatch" suggest something else to you, but ceval.c really is the code that iterates over a list of opcodes and executes the associated computations. This is absolutely 100% the part of Python that is the interpreter. The module that generates Python opcodes is the "compiler" (or "bytecode compiler"), and the article specifically points out that it's not included.
- gsnedders 6y ago
  But at what point do function calls from ceval.c stop counting as part of the interpreter? Okay, calling a C function clearly at some point ceases being part of the interpreter, but is the entirety of an attribute lookup (i.e., executing the LOAD_ATTR inst) on an ordinary Python object part of the interpreter or the runtime? In plenty of VMs the object representation is an intrinsic part of the VM design, with the VM having deep knowledge of it.
  - tom_mellior 6y ago
    That's a very blurry distinction, and I'm not very interested in it. I was correcting the OP's first two paragraphs, I didn't take a stance on the third.
astrobe_ 6y ago
Etymology says that "interpreter" is made of "inter-" (between) and "-pretium" (price, value, worth, merit). So an interpret is a middle man/woman whose merit is to help people communicate, I guess. For interpreted languages, there are indeed two interpreters: the one that translates from source to bytecode (or whatever technique the implementation uses) - in Forth it is called the "outer interpreter' - and the one who translates bytecode to machine code (in Forth it is called the "inner interpreter"). That distinction between those two interpreters allows to understand, for instance, how you can "run" Lisp by compiling Lua bytecode. "Runtime" is to me a fuzzy word, similar to "frameworks" that are actually just libraries. I am not in position to be a terminology Nazi but I think there's some misuse sometimes. To me the runtime of a language is everything the "inner interpreter" does. This includes "bytecode dispatch" and indeed, garbage collection but also more trivial things like performing the additions the user asks for.
- tom_mellior 6y ago
  > For interpreted languages, there are indeed two interpreters: the one that translates from source to bytecode (or whatever technique the implementation uses) - in Forth it is called the "outer interpreter' - and the one who translates bytecode to machine code (in Forth it is called the "inner interpreter"). This seems to be nonstandard usage that is entirely limited to Forth. Standard usage for the translator from source code to bytecode is "compiler". I'm not aware of any exceptions to to this except for Forth. > That distinction between those two interpreters allows to understand, for instance, how you can "run" Lisp by compiling Lua bytecode. I, for one, don't understand what you mean by this.
  - astrobe_ 6y ago
    > This seems to be nonstandard usage that is entirely limited to Forth Certainly. But sometimes artificially changing the terms avoids misunderstandings. > I, for one, don't understand what you mean by this. I was referring to what is usually called a "transpiler": the "compiler" translates source code for language A (eg Lisp) into bytecode for language B (eg Lua), then the "runtime" for language B is used to translate bytecode B into actual actions. So you end up with an "interpreter" (actually two interpreters in the etymological sense) that takes in Lisp source code but uses Lua runtime to execute it.

tom_mellior 6y ago

> If I understand correctly, they call the module generating Python opcodes from Python code the "interpreter", No, you misunderstand. They explicitly define the interpreter as "ceval.c which evaluates and dispatches Python opcodes". Maybe "evaluate and dispatch" suggest something else to you, but ceval.c really is the code that iterates over a list of opcodes and executes the associated computations. This is absolutely 100% the part of Python that is the interpreter. The module that generates Python opcodes is the "compiler" (or "bytecode compiler"), and the article specifically points out that it's not included.

gsnedders 6y ago
But at what point do function calls from ceval.c stop counting as part of the interpreter? Okay, calling a C function clearly at some point ceases being part of the interpreter, but is the entirety of an attribute lookup (i.e., executing the LOAD_ATTR inst) on an ordinary Python object part of the interpreter or the runtime? In plenty of VMs the object representation is an intrinsic part of the VM design, with the VM having deep knowledge of it.
- tom_mellior 6y ago
  That's a very blurry distinction, and I'm not very interested in it. I was correcting the OP's first two paragraphs, I didn't take a stance on the third.

astrobe_ 6y ago

Etymology says that "interpreter" is made of "inter-" (between) and "-pretium" (price, value, worth, merit). So an interpret is a middle man/woman whose merit is to help people communicate, I guess. For interpreted languages, there are indeed two interpreters: the one that translates from source to bytecode (or whatever technique the implementation uses) - in Forth it is called the "outer interpreter' - and the one who translates bytecode to machine code (in Forth it is called the "inner interpreter"). That distinction between those two interpreters allows to understand, for instance, how you can "run" Lisp by compiling Lua bytecode. "Runtime" is to me a fuzzy word, similar to "frameworks" that are actually just libraries. I am not in position to be a terminology Nazi but I think there's some misuse sometimes. To me the runtime of a language is everything the "inner interpreter" does. This includes "bytecode dispatch" and indeed, garbage collection but also more trivial things like performing the additions the user asks for.

tom_mellior 6y ago
> For interpreted languages, there are indeed two interpreters: the one that translates from source to bytecode (or whatever technique the implementation uses) - in Forth it is called the "outer interpreter' - and the one who translates bytecode to machine code (in Forth it is called the "inner interpreter"). This seems to be nonstandard usage that is entirely limited to Forth. Standard usage for the translator from source code to bytecode is "compiler". I'm not aware of any exceptions to to this except for Forth. > That distinction between those two interpreters allows to understand, for instance, how you can "run" Lisp by compiling Lua bytecode. I, for one, don't understand what you mean by this.
- astrobe_ 6y ago
  > This seems to be nonstandard usage that is entirely limited to Forth Certainly. But sometimes artificially changing the terms avoids misunderstandings. > I, for one, don't understand what you mean by this. I was referring to what is usually called a "transpiler": the "compiler" translates source code for language A (eg Lisp) into bytecode for language B (eg Lua), then the "runtime" for language B is used to translate bytecode B into actual actions. So you end up with an "interpreter" (actually two interpreters in the etymological sense) that takes in Lisp source code but uses Lua runtime to execute it.