We need better and more rigorous terms in computing science. This use of the compiler word blurs the meaning of interpreted vs compiled languages.
I was under the assumption that it would generate executable machine code, not Lua source code.
We need better and more rigorous terms in computing science. This use of the compiler word blurs the meaning of interpreted vs compiled languages.
I was under the assumption that it would generate executable machine code, not Lua source code.
The definition of compiler has never assumed generating executable machine code. Already in the 1970s, Pascal compilers have generated P-code (a form of "bytecode" in Java parlance), which was then interpreted. In the 1980s, Turbo Pascal produced machine code directly.
I've seen the neologism "transpiler" being very frowned upon by the academic programming language community precisely because a compiler is a compiler, no matter the output language — my use of "compiler" there was precisely because of my academic background.
I don't mind the term "transpiler" myself if it helps you understand it's a source-to-source compiler, but then, you don't see people calling the Nim compiler, which generates C code then compiles it into machine code, a "transpiler", even though it is a source-to-source compiler. In the end, "compiler" is the all-encompassing term for a program that takes code in one language and produces code in another, be it high-level or machine language — and yes, that means that technically an assembler is a compiler as well. And since we're talking assembler, most C compilers do not generate executable machine code either: gcc produces assembly, which is then turned into machine code by gas. So gcc is a source-to-source compiler? Is Turbo Pascal more of a compiler than gcc? I could just as well add an output step in the Teal compiler to produce an executable in the output using the same techniques of the Pascal compilers of the 70s. I don't think that would make it more or less of a compiler.
As you can see, the distinction of "what is a transpiler" reduces to "what is source code" or "what is a high-level language", the latter especially having a very fuzzy definition, so in the end my sociological observation on the uses of "transpiler" vs. "compiler" tends to boil down to people's perceptions of "what is a Real, Hardcore Compiler". But being a "transpiler" or not doesn't say anything about the project's "hardcoreness" either — I'm sure the TypeScript compiler which generates JavaScript is a lot more complex than a lot of compilers out there which generate machine code.
You can have terms that are precise and unchanging, and terms that are useful in today's computing landscape, but you can't have both.
Grace Hopper, who coined the term "compiler" used it for what we'd today call a "linker-loader".
Many C/C++ compilers emit textual assembly code which is then assembled as a separate step to machine code. The machine doesn't execute assembly, so are those still "compilers"?
Nikaus Wirth's Pascal compiler compiled to bytecode, not machine code. Likewise, almost all Java and C# compilers today target bytecode and not machine code. Are they compilers? What if I take that bytecode and run it on a Java processor (https://en.wikipedia.org/wiki/Java_processor)? Was javac not a compiler before Java processors existed but spontaneously became a compiler once the chip was shipped?
The V8 JavaScript engine parses your JS, compiles it to bytecode, runs that in an interpreter, uses the results of that to re-compile the code to machine code, and runs that again. The user never explicitly invokes a compiler or sees any machine code written to disk. Is V8 an interpreter? A compiler? Both? If you never run a JS program long enough for the JIT to kick in, is it still a compiler?
Some emulators for game consoles take game ROMs compiled to machine code for a different architecture and interpret them a virtual instruction at a time. Others take the ROM and recompile its machine code to new machine code for the host architecture, so they just treat the original machine code as an input format. Does that mean whether the ROM contains "executable machine code" versus "source code" depends on which emulator you run it in?
When Apple transitioned from 68k to PowerPC, newer PowerPC Macs ran old 68k apps in an emulator. Did those apps still contain "executable machine code"?
Modern CPUs implement large instruction sets by translating them down to microcode. If you compile to the larger ISA which is not what the chip actually executes, are you still outputing "executable machine code"?