<p>Are there any languages that are interpreted in something interpreted, like Python? If so, what are the advantages?</p>

<interpreters><high-level-languages>
Are there any languages interpreted twice?
CC BY-SA 4.0
2023-11-04T18:26:06.013Z
Arguably languages implemented in a JVM language are intepreted, though I digress
Seggan
CC BY-SA 4.0
2023-11-04T18:26:29.330Z
Many toy and/or golfing languages are implemented in Python or JavaScript
Seggan
CC BY-SA 4.0
2023-11-04T19:11:09.277Z
I do not see any advantages other than 'ease' of writing an implementation if writing an interpreter in an interpreted language is somehow easier than with a compiled language.
CPlus
<p>One issue not mentioned in the other answers so far is garbage collection.</p>
<p>As already mentioned, being &quot;interpreted&quot; is a property of a language implementation, not a property of the language itself, as the same language could have both a compiler and an interpreter. However, we can talk about dynamic languages, i.e. those with features like dynamic types, runtime type checks or duck typing, construction of new types at runtime, and especially mechanisms like <code>eval</code> or <code>exec</code> which evaluate code from strings at runtime. Dynamic languages tend to be implemented as interpreters, though there are several notable exceptions.</p>
<p>Dynamic languages also tend to be garbage-collected. So, when you are implementing an interpreter for a dynamic language, there is a benefit to writing it in another dynamic language, since your interpreter will naturally take advantage of the garbage collection in the host language. In contrast, if you are writing a compiler (to a target like an assembly language, or LLVM IR), then you will need to explicitly implement garbage collection. That said, a compiler targeting another dynamic language (e.g. compiling Python to Javascript) would also get garbage collection &quot;for free&quot;.</p>

CC BY-SA 4.0
2023-11-04T22:57:22.527Z
2023-11-05T12:32:42.407Z
2023-11-05T12:32:42.407Z
kaya3
CC BY-SA 4.0
2023-11-05T01:18:36.203Z
"Dynamic languages tend to be implemented as interpreters" – Do they? All mainstream Python implementations, Ruby implementations, and ECMAScript implementations have compilers, as do PHP and Erlang. The last mainstream dynamic language implementation I can remember being interpreted was Ruby's MRI, which has been obsolete for 10 years now. Its successor, YARV, has a compiler. The only dynamic languages I can think of which have mainly interpreted implementations are shells like Bash and Zsh and DSLs like Sed, Ed, Awk, etc.
Jörg W Mittag
CC BY-SA 4.0
2023-11-05T12:27:29.130Z
@JörgWMittag If you are only talking about mainstream languages then that is true, to an extent; CPython is both a compiler to CPython bytecode, and a bytecode interpreter, for example.
kaya3
<p>Languages aren't interpreted. Nor are they compiled. Languages just <em>are</em>.</p>
<p>The term &quot;interpreted language&quot; is non-sensical. It is a <a href="https://wikipedia.org/wiki/Category_mistake" rel="nofollow noreferrer"><em>category error</em></a>. <a href="https://cs.brown.edu/%7Esk/" rel="nofollow noreferrer">Shriram Krishnamurthi</a> once said in an interview something like &quot;if English were a typed language, 'interpreted language' would be a type error&quot;.</p>
<p>A particular <em>implementation</em> of a language may use interpretation or compilation (or, in most modern mainstream high-performance implementations, likely both), but that is purely a trait of the <em>implementation</em>, not the language.</p>
<p>Therefore, the question doesn't make sense.</p>
<p>Every language can be implemented by an interpreter. Every language can be implemented by a compiler. You can <a href="https://wikipedia.org/wiki/Partial_evaluation#Futamura_projections" rel="nofollow noreferrer">automatically derive a compiler from an interpreter</a>. You can easily derive an interpreter from a compiler.</p>
<p>The vast majority of modern mainstream languages have both interpreted and compiled implementations.</p>
<p>One <em>possible</em> interpretation of the question is: &quot;has there ever been an instance where there were two levels of interpretation&quot;, and the answer is that this happens all the time. In fact, a CPU is nothing but an interpreter for its instruction set, so <em>every time</em> you run a natively compiled interpreter, you are using two levels of interpretation. E.g., when you run a <a href="https://python.org/" rel="nofollow noreferrer">Python</a> program in <a href="https://github.com/python/cpython" rel="nofollow noreferrer">CPython</a>, CPython first <em>compiles</em> the Python program into CPython byte code, then <a href="https://devguide.python.org/internals/interpreter/" rel="nofollow noreferrer">it <em>interprets</em> this CPython byte code</a>, whilst itself being interpreted by the CPU.</p>
<p>If you think that calling the CPU an interpreter is cheating, you can use an emulator such as <a href="https://jpc.sourceforge.net/" rel="nofollow noreferrer">JPC</a>, <a href="https://bellard.org/tinyemu/" rel="nofollow noreferrer">TinyEMU</a>, <a href="https://bellard.org/jslinux/" rel="nofollow noreferrer">JSLinux</a>, <a href="http://s-macke.github.io/jor1k/" rel="nofollow noreferrer">jor1k</a>, <a href="http://copy.sh/v86/" rel="nofollow noreferrer">v86</a>, <a href="https://github.com/riscv-software-src/riscv-angel" rel="nofollow noreferrer">Angel</a>, <a href="https://qemu.org/" rel="nofollow noreferrer">QEmu</a>, or many others.</p>
<p>Or, a much simpler argument: many interpreters are written in C. <a href="https://root.cern.ch/root/html534/guides/users-guide/CINT.html" rel="nofollow noreferrer">There are interpreters for C</a>. Ergo, you can run an interpreter written in C on an interpreter for C.</p>

CC BY-SA 4.0
2023-11-04T20:39:48.973Z
2023-11-04T20:39:48.973Z
Jörg W Mittag
CC BY-SA 4.0
2023-11-05T02:45:08.930Z
This is a little pedantic. While compilation and interpretation and "language" are overused and underspecified, sure, it's *pretty clear* the OP is talking about implementations of languages in a language that itself is implemented in a bytecode interpreter or higher.
apropos
<p>Many interpreters are written in interpreted languages; this is really a property of the implementation rather than the language. The advantage generally is to be able to use that host language for implementing the other, for convenience, existing knowledge, or particular features of the language that make it suitable for implementing other languages. These are just the same reasons you might use those languages for any other program too.</p>
<p>Implementing an interpreter under an interpreter isn’t generally either easier or harder than implementing it under a compiler. The host language could be implemented either way (and sometimes there are implementations both ways — like Python!), and typical interpreters could run on any implementation of the language they’re written in. The short answer is then that <strong>yes</strong>, they can be and are built that way, but no, there’s no strong reason in general to do it one way or the other.</p>
<hr />
<p>While there’s generally no <em>inherent</em> difference to an interpreter in an interpreted language, there are a few situations where it can be relevant:</p>
<ul>
<li><a href="https://en.wikipedia.org/wiki/Meta-circular_evaluator" rel="noreferrer">Metacircular interpreters</a> are a style of interpreter implemented within the language they’re interpreting, leveraging the host language’s functionality to execute code. These aren’t necessarily built on top of interpreters, but interpreters do often expose more reflective facilities to do this, and sometimes you can stack nesting dolls of interpreters this way.</li>
<li>Domain-specific languages used for things like configuration and special-purpose business logic within a program are generally interpreted, and implemented in the host language of that program. Some implementation strategies are more viable in interpreters, and that can make creating the DSL in the first place more likely.</li>
<li>Prototyping or exploratory language design within an interpreter can be more convenient if only for avoiding compile cycles, but dynamic <code>eval</code> in particular is very rare in compilers and can be useful.</li>
<li>Languages targeting platforms built around interpreted languages, like the web, need to conform to that restriction.</li>
<li>Bytecode systems are interpreted, from a certain point of view, so you could argue that all languages compiling to those are interpreted; it’s harder to distinguish the standard Java, C#, Python, and JavaScript implementations from this perspective than you might first think, and there are many interpreters written in the first two as well. This is quibbling semantics, however.</li>
</ul>
<p>I have written many interpreters in both (typically-) compiled and interpreted languages. The reasons for one or another have all been external, determined by other systems I was working with or my whims and preferences at the time, and could have been overcome if something had been a little different. That is also the case in general: other factors dominate the decision rather than the implementation strategy of the host language.</p>

CC BY-SA 4.0
2023-11-04T19:08:01.150Z
2023-11-04T19:21:41.063Z
2023-11-04T19:21:41.063Z
Michael Homer
# Are there any languages interpreted twice?
Posted by: username_0 on 2023-11-04
Are there any languages that are interpreted in something interpreted, like Python? If so, what are the advantages?
**Tags:** interpreters high-level-languages
> **Comments:**
> **username_1**: Arguably languages implemented in a JVM language are intepreted, though I digress  
> **username_1**: Many toy and/or golfing languages are implemented in Python or JavaScript  
> **username_2**: I do not see any advantages other than 'ease' of writing an implementation if writing an interpreter in an interpreted language is somehow easier than with a compiled language.  
---
## 3 answers
### Answer by username_6 on 2023-11-04. Score: 7 | Accepted answer
Many interpreters are written in interpreted languages; this is really a property of the implementation rather than the language. The advantage generally is to be able to use that host language for implementing the other, for convenience, existing knowledge, or particular features of the language that make it suitable for implementing other languages. These are just the same reasons you might use those languages for any other program too.

Implementing an interpreter under an interpreter isn’t generally either easier or harder than implementing it under a compiler. The host language could be implemented either way (and sometimes there are implementations both ways — like Python!), and typical interpreters could run on any implementation of the language they’re written in. The short answer is then that **yes**, they can be and are built that way, but no, there’s no strong reason in general to do it one way or the other.

---

While there’s generally no *inherent* difference to an interpreter in an interpreted language, there are a few situations where it can be relevant:

* [Metacircular interpreters](https://en.wikipedia.org/wiki/Meta-circular_evaluator) are a style of interpreter implemented within the language they’re interpreting, leveraging the host language’s functionality to execute code. These aren’t necessarily built on top of interpreters, but interpreters do often expose more reflective facilities to do this, and sometimes you can stack nesting dolls of interpreters this way.
* Domain-specific languages used for things like configuration and special-purpose business logic within a program are generally interpreted, and implemented in the host language of that program. Some implementation strategies are more viable in interpreters, and that can make creating the DSL in the first place more likely.
* Prototyping or exploratory language design within an interpreter can be more convenient if only for avoiding compile cycles, but dynamic `eval` in particular is very rare in compilers and can be useful.
* Languages targeting platforms built around interpreted languages, like the web, need to conform to that restriction.
* Bytecode systems are interpreted, from a certain point of view, so you could argue that all languages compiling to those are interpreted; it’s harder to distinguish the standard Java, C#, Python, and JavaScript implementations from this perspective than you might first think, and there are many interpreters written in the first two as well. This is quibbling semantics, however.

I have written many interpreters in both (typically-) compiled and interpreted languages. The reasons for one or another have all been external, determined by other systems I was working with or my whims and preferences at the time, and could have been overcome if something had been a little different. That is also the case in general: other factors dominate the decision rather than the implementation strategy of the host language.
---
### Answer by username_4 on 2023-11-04. Score: 3
Languages aren't interpreted. Nor are they compiled. Languages just *are*.

The term "interpreted language" is non-sensical. It is a [*category error*](https://wikipedia.org/wiki/Category_mistake). [Shriram Krishnamurthi](https://cs.brown.edu/%7Esk/) once said in an interview something like "if English were a typed language, 'interpreted language' would be a type error".

A particular *implementation* of a language may use interpretation or compilation (or, in most modern mainstream high-performance implementations, likely both), but that is purely a trait of the *implementation*, not the language.

Therefore, the question doesn't make sense.

Every language can be implemented by an interpreter. Every language can be implemented by a compiler. You can [automatically derive a compiler from an interpreter](https://wikipedia.org/wiki/Partial_evaluation#Futamura_projections). You can easily derive an interpreter from a compiler.

The vast majority of modern mainstream languages have both interpreted and compiled implementations.

One *possible* interpretation of the question is: "has there ever been an instance where there were two levels of interpretation", and the answer is that this happens all the time. In fact, a CPU is nothing but an interpreter for its instruction set, so *every time* you run a natively compiled interpreter, you are using two levels of interpretation. E.g., when you run a [Python](https://python.org/) program in [CPython](https://github.com/python/cpython), CPython first *compiles* the Python program into CPython byte code, then [it *interprets* this CPython byte code](https://devguide.python.org/internals/interpreter/), whilst itself being interpreted by the CPU.

If you think that calling the CPU an interpreter is cheating, you can use an emulator such as [JPC](https://jpc.sourceforge.net/), [TinyEMU](https://bellard.org/tinyemu/), [JSLinux](https://bellard.org/jslinux/), [jor1k](http://s-macke.github.io/jor1k/), [v86](http://copy.sh/v86/), [Angel](https://github.com/riscv-software-src/riscv-angel), [QEmu](https://qemu.org/), or many others.

Or, a much simpler argument: many interpreters are written in C. [There are interpreters for C](https://root.cern.ch/root/html534/guides/users-guide/CINT.html). Ergo, you can run an interpreter written in C on an interpreter for C.
> **Comments:**
> **username_5** (2023-11-05): This is a little pedantic. While compilation and interpretation and "language" are overused and underspecified, sure, it's *pretty clear* the OP is talking about implementations of languages in a language that itself is implemented in a bytecode interpreter or higher.  
---
### Answer by username_3 on 2023-11-04. Score: 2
One issue not mentioned in the other answers so far is garbage collection.

As already mentioned, being "interpreted" is a property of a language implementation, not a property of the language itself, as the same language could have both a compiler and an interpreter. However, we can talk about dynamic languages, i.e. those with features like dynamic types, runtime type checks or duck typing, construction of new types at runtime, and especially mechanisms like `eval` or `exec` which evaluate code from strings at runtime. Dynamic languages tend to be implemented as interpreters, though there are several notable exceptions.

Dynamic languages also tend to be garbage-collected. So, when you are implementing an interpreter for a dynamic language, there is a benefit to writing it in another dynamic language, since your interpreter will naturally take advantage of the garbage collection in the host language. In contrast, if you are writing a compiler (to a target like an assembly language, or LLVM IR), then you will need to explicitly implement garbage collection. That said, a compiler targeting another dynamic language (e.g. compiling Python to Javascript) would also get garbage collection "for free".
> **Comments:**
> **username_4** (2023-11-05): "Dynamic languages tend to be implemented as interpreters" – Do they? All mainstream Python implementations, Ruby implementations, and ECMAScript implementations have compilers, as do PHP and Erlang. The last mainstream dynamic language implementation I can remember being interpreted was Ruby's MRI, which has been obsolete for 10 years now. Its successor, YARV, has a compiler. The only dynamic languages I can think of which have mainly interpreted implementations are shells like Bash and Zsh and DSLs like Sed, Ed, Awk, etc.  
> **username_3** (2023-11-05): @JörgWMittag If you are only talking about mainstream languages then that is true, to an extent; CPython is both a compiler to CPython bytecode, and a bytecode interpreter, for example.  
---
