4 ms·

> For interpreted languages, there are indeed two interpreters: the one that translates from source to bytecode (or whatever technique the implementation uses)

> 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
  Conflating compilation and interpretation does not "avoid misunderstandings". Quite on the contrary. Compilation and interpretation do very different things. Example: Imagine a Lisp program that prints "hello world" in an infinite loop. If you compile this to Lua bytecode, the compilation process (a) will not print "hello world", and (b) will not run into an infinite loop. Running the Lua bytecode will (a) print "hello world", and (b) will do so in an infinite loop. Surely you agree these are very different things. Compilation translates input code into output code without executing it. Interpretation executes the input code, usually without further translating it into another representation. Why would you confuse them by trying to apply the same term to them when we have very good distinct terms for these distinct concepts? Etymology does not come into it. Words mean what they mean, not what some related word might have meant in the past.
  - astrobe_ 6y ago
    > Compilation translates input code into output code without executing it. I think it is not totally true. There's Forth immediate words, there's Lisp macros and to a lesser extend there's C++ templates (which are Turing-complete). > Why would you confuse them by trying to apply the same term to them when we have very good distinct terms for these distinct concepts? Because from a slightly more generalized perspective, that's the same thing. Compilation: translate source code to bytecode Interpretation: translate bytecode into side-effects If I say that side-effects can be formalized into a language, I think I have most Haskell programmers with me. If you run your program in a VM, and compare examine the bytes of the snapshots before and after. You can use diff to turn those changes into another language. And you can use patch to replay those exact changes. > Etymology does not come into it. Words mean what they mean, not what some related word might have meant in the past. You realize you say that on Hacker News?
    - tom_mellior 6y ago
      > There's Forth immediate words, there's Lisp macros and to a lesser extend there's C++ templates (which are Turing-complete). This is true. It's not what we have been discussing so far, but yes, there is also a notion of executing code at compile time. We might call compile-time code execution "outer interpretation", but that would still be less clear than "compile-time code execution". It would also be different from what you had wanted to call "outer interpretation" so far. > Compilation: translate source code to bytecode Interpretation: translate bytecode into side-effects https://en.wiktionary.org/wiki/translate#Verb https://en.wiktionary.org/wiki/translate#Verb lists three senses of "translate", the first two of which have six sub-senses each. Non-technical language can be vague. That is why we introduce technical terms to speak of technical things. > You realize you say that on Hacker News? I don't know what you are trying to tell me. Which is a fitting end to this discussion about your insistence on communicating less clearly than you might.
      - astrobe_ 6y ago
        > https://en.wiktionary.org/wiki/translate#Verb https://en.wiktionary.org/wiki/translate#Verb lists three senses of "translate" And so do "execute" and "interpret". The fact that you are counting the second set of meanings of translate, which is archaic (who said "words have meaning, not what some related word might have meant in the past"?), shows that you know how weak your argument is. > That is why we introduce technical terms to speak of technical things. Yep. I introduced two technical terms "outer interpreter" and "inner interpreter", along with their definitions. > I don't know what you are trying to tell me. Which is a fitting end to this discussion about your insistence on communicating less clearly than you might. Being able to accept that others may have a different terminology, embrace it and speak with their words: this is communication. You don't have a monopoly on the meaning of words.

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
Conflating compilation and interpretation does not "avoid misunderstandings". Quite on the contrary. Compilation and interpretation do very different things. Example: Imagine a Lisp program that prints "hello world" in an infinite loop. If you compile this to Lua bytecode, the compilation process (a) will not print "hello world", and (b) will not run into an infinite loop. Running the Lua bytecode will (a) print "hello world", and (b) will do so in an infinite loop. Surely you agree these are very different things. Compilation translates input code into output code without executing it. Interpretation executes the input code, usually without further translating it into another representation. Why would you confuse them by trying to apply the same term to them when we have very good distinct terms for these distinct concepts? Etymology does not come into it. Words mean what they mean, not what some related word might have meant in the past.
- astrobe_ 6y ago
  > Compilation translates input code into output code without executing it. I think it is not totally true. There's Forth immediate words, there's Lisp macros and to a lesser extend there's C++ templates (which are Turing-complete). > Why would you confuse them by trying to apply the same term to them when we have very good distinct terms for these distinct concepts? Because from a slightly more generalized perspective, that's the same thing. Compilation: translate source code to bytecode Interpretation: translate bytecode into side-effects If I say that side-effects can be formalized into a language, I think I have most Haskell programmers with me. If you run your program in a VM, and compare examine the bytes of the snapshots before and after. You can use diff to turn those changes into another language. And you can use patch to replay those exact changes. > Etymology does not come into it. Words mean what they mean, not what some related word might have meant in the past. You realize you say that on Hacker News?
  - tom_mellior 6y ago
    > There's Forth immediate words, there's Lisp macros and to a lesser extend there's C++ templates (which are Turing-complete). This is true. It's not what we have been discussing so far, but yes, there is also a notion of executing code at compile time. We might call compile-time code execution "outer interpretation", but that would still be less clear than "compile-time code execution". It would also be different from what you had wanted to call "outer interpretation" so far. > Compilation: translate source code to bytecode Interpretation: translate bytecode into side-effects https://en.wiktionary.org/wiki/translate#Verb https://en.wiktionary.org/wiki/translate#Verb lists three senses of "translate", the first two of which have six sub-senses each. Non-technical language can be vague. That is why we introduce technical terms to speak of technical things. > You realize you say that on Hacker News? I don't know what you are trying to tell me. Which is a fitting end to this discussion about your insistence on communicating less clearly than you might.
    - astrobe_ 6y ago
      > https://en.wiktionary.org/wiki/translate#Verb https://en.wiktionary.org/wiki/translate#Verb lists three senses of "translate" And so do "execute" and "interpret". The fact that you are counting the second set of meanings of translate, which is archaic (who said "words have meaning, not what some related word might have meant in the past"?), shows that you know how weak your argument is. > That is why we introduce technical terms to speak of technical things. Yep. I introduced two technical terms "outer interpreter" and "inner interpreter", along with their definitions. > I don't know what you are trying to tell me. Which is a fitting end to this discussion about your insistence on communicating less clearly than you might. Being able to accept that others may have a different terminology, embrace it and speak with their words: this is communication. You don't have a monopoly on the meaning of words.