You were arguing that the word “perfectly describes translating from one formal language into another”. The word doesn’t do that, as it’s not descriptive in that sense.
Furthermore, translating from (say) JSON to XML is also “translating from one formal language into another”, but that’s not an example of what we mean by “compiler”.
So what do we mean? That’s actually not easy to define. Defining it as translating from one programming language into a different programming language isn’t quite correct, because machine-code binaries aren’t a programming language. Defining it as translating from a programming language into a different representation preserving the program semantics is also not quite correct, because e.g. pretty-printing to HTML would arguably fit that definition.
Clearly there’s some general definition of what we mean by “compiler”, even if I’m failing to find a precise and correct wording for it here. But there’s also the more narrow meaning of “translating from a programming language into object code”, which is what is usually meant in the majority of cases. Because we don’t have a separate word for that narrower definition, there is some ambiguity. The word “transpiler” resolves the ambiguity in one direction. In the other direction, the ambiguity is usually resolved by assuming that “compiler” means “to object code” by default when the context doesn’t specify otherwise.
> machine-code binaries aren’t a programming language
Machine-code binaries aren't (they are programs), but ISA of a CPU is.
I'd plug in a requirement of Turing-completeness for the source and destination language, and at that point the "semantics-preserving" variant makes perfect sense to me. Although canonically textbooks and Wikipedia don't seem to require that, so I'm fine accepting a definition not requiring Turing-completeness, just preservation of semantics.
It makes sense to drop Turing-completeness. Many interesting languages are not Turing complete.
Perhaps the most practical example: just-in-time compilation of regular expressions to native code via LLVM. Regular expressions are not Turing complete.
Another example: take Agda as a source language. Agda is deliberately not Turing-complete, but can express almost any program you might be interested in. (Basically, Agda only allows you to express terminating programs. That's why it's not Turing complete.)
> Furthermore, translating from (say) JSON to XML is also “translating from one formal language into another”, but that’s not an example of what we mean by “compiler”.
I'd be perfectly happy to describe that as a compiler.
Furthermore, translating from (say) JSON to XML is also “translating from one formal language into another”, but that’s not an example of what we mean by “compiler”.
So what do we mean? That’s actually not easy to define. Defining it as translating from one programming language into a different programming language isn’t quite correct, because machine-code binaries aren’t a programming language. Defining it as translating from a programming language into a different representation preserving the program semantics is also not quite correct, because e.g. pretty-printing to HTML would arguably fit that definition.
Clearly there’s some general definition of what we mean by “compiler”, even if I’m failing to find a precise and correct wording for it here. But there’s also the more narrow meaning of “translating from a programming language into object code”, which is what is usually meant in the majority of cases. Because we don’t have a separate word for that narrower definition, there is some ambiguity. The word “transpiler” resolves the ambiguity in one direction. In the other direction, the ambiguity is usually resolved by assuming that “compiler” means “to object code” by default when the context doesn’t specify otherwise.