On Sun, Mar 7, 2021 at 9:42 AM Mirko via Python-list <python-list@python.org> wrote: > I even wonder why they have tried. Writing a universal > compiler/interpreter sounds logically impossible to me, Here's a > simple Python expression: > > >>> 3+3*5 > 18 > > And here's the same expression in (GNU) Smalltalk: > > st> 3+3*5 > 30 > > > How would such a universal compiler know which evaluation strategy > to follow, if not by writing a parser end evaluator for every > supported language? And if it's hard for this simple problem, how > about more complex cases.
There are two ways in which "universal compiler/interpreter" can definitely make sense, but neither of them is what he's trying to do. 1) A bytecode or machine code that all other languages can be compiled to. For example, I'm running an amd64 CPU, so on this computer, everything ultimately gets executed as amd64 bytecode. It's also possible to have higher level bytecodes, or even textual languages (Asm.js can be used as a compilation target). 2) "Compiler compilers" and grammar parsers. These are an excellent tool for people designing programming language compilers, as they make it a lot easier to describe the syntax and semantics for the language. Both of them are tools that programming language developers use. They don't replace language interpreters any more than a JSON parser replaces the need to open files. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
