It is possible to create compilers for dynamic languages without losing his dynamic characteristics? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

Are there some set of reasons that make it impossible for dynamic languages ​​such as Python or Ruby to be compiled instead of interpreted without losing any of his dynamics characteristics?

Of course one the requirements to that hypothetical compiler is that those languages doesn't lose any of his characteristics like metaprogramming, extend objects, add code or modify type system in runtime.

Summarizing, it is possible to create a Ruby or Python compiler without losing any of his characteristics as dynamic programming languages?

Answer 1

Yes, it is definitely possible to create compilers for dynamic languages. There are a myriad of examples of compilers for dynamic languages in the wild:

• CPython is an implementation of the Python programming language which has a Python compiler.
• PyPy is an implementation of the Python programming language which has a Python compiler.
• Jython is an implementation of the Python programming language which has a Python compiler.
• IronPython is an implementation of the Python programming language which has a Python compiler.
• Pynie is an implementation of the Python programming language which has a Python compiler.
• YARV is an implementation of the Ruby programming language which has a Ruby compiler.
• Rubinius is an implementation of the Ruby programming language which has a Ruby compiler.
• MacRuby is an implementation of the Ruby programming language which has a Ruby compiler.
• JRuby is an implementation of the Ruby programming language which has a Ruby compiler.
• IronRuby is an implementation of the Ruby programming language which has a Ruby compiler.
• MagLev is an implementation of the Ruby programming language which has a Ruby compiler.
• Quercus is an implementation of the PHP programming language which has a PHP compiler.
• P8 is an implementation of the PHP programming language which has a PHP compiler.
• V8 is an implementation of the ECMAScript programming language which has an ECMAScript compiler.

In general, every language can be implemented by a compiler, and every language can be implemented by an interpreter. It is also possible to automatically derive a compiler from an interpreter and vice-versa.

Most modern language implementations use both interpretation and compilation, sometimes even several compilers. Take Rubinius, for example: first Ruby code is compiled to Rubinius bytecode. Rubinius bytecode is then interpreted by the Rubinius VM. Code which has been interpreted several times is then compiled to Rubinius Compiler IR, which is then compiled to LLVM IR, which is then compiled to "native code" (whatever that is). So, Rubinius has one interpreter and three compilers.

V8 is a different example. It actually has no interpreter, but two different compilers: one very fast, very memory-efficient compiler which produces unoptimized, somewhat slow code. Code which has been run multiple times is then thrown away, and compiled again with the second compiler, which produces aggressively optimized code but takes more time and uses more memory during compilation.

However, in the end, you cannot run code without an interpreter. A compiler cannot run code. A compiler translates a program from one language into a different language. That's it. You can translate all you want, in the end, something has to run the code, and that thing is an interpreter. It might be implemented in software or in silicon, but it still is an interpreter.

Answer 2

I'll just assume by "compile" you mean "compile to native machine code" and leave it for others to challenge this very narrow definition. The answer is a resounding yes. In fact, people are doing this right now:

• Nuitka
• Cython (actually not Python, but very close and could be made to support full Python).
• Various "freezing" tools, though technically those only package the bytecode and a bytecode interpreter into one binary.

However, such a compiler can't perform many (I'd say effectively zero) optimizations, so the resulting code is basically equivalent to what a simple-minded interpreter would do and you only save interpretation overhead (and you lose some nice properties of interpreters, including compact code and faster turnaround). In other words: Dynamic, correct, fast - choose two (full disclosure: the accepted answer is mine).