It's hard to get more canonical than the Dragon Book. The Dragon Book (2nd Ed.) says this in section 1.2: "Up to this point we have treated a compiler as a single box that maps a source program into a semantically equivalent target program."
So, the most canonical source doesn't include an explicit mention of high-level to low-level (though there may be sources I'm missing). But in my experience, that's definitely the connotation. Otherwise, the term transpiler, which is connoted with not outputting low-level code, never would have arisen.
re: transpiler – all I'm saying is that the term arose because people associated compilers with low-level outputs.
In summary, there don't appear to be canonical definitions of compilers as having low-level outputs, but for some reason many speak of them that way.
Compiler: one who compiles - first use 14th century
And for compile:
transitive verb
1 : to compose out of materials from other documents
2 : to collect and edit into a volume
3 : to build up gradually <compiled a record of four wins and two losses>
Origin: Middle English, from Anglo-French compiler, from Latin compilare to plunder.
Synonyms: anthologize, collect
Note, I've skipped the dictionary references to computer use, as the seem overly (wrongly) focused on "top down" compilation...
Wow. Snap. Except we never got it to compile to English (well, we probably could have but the result would have had deeply nested bracketed clauses...)
I'd be surprised if anyone did.
The use of transpiler is more about audience expectation, a specificity.
It's shorter than writing "source-to-source compiler", and acknowledges compiler as its superset, right there in its name
I assume other language users and authors suffer the same kind of comments on a regular basis.
And that the cognitive dissonance to say:
> ...is not a compiler, it's a transpiler, since it compiles to...
is alive and well.
Mea culpa.
Which is also still a compiler.
Likewise, there are compilers I wouldn't call transpilers.
And what verb do you use with a transpiler? It compiles one form into another.
A transpiler is a source-to-source compiler. What you do with the output afterwards hardly matters, when it is performing the act of compilation.
There is no distinction here. One is merely a subset of the other. Which is good for communicating purpose, but you can't just assume one is seperate from the other when they employ the same process.
A compiler may not compile to a source language, though it might.
A transpiler is a compiler that compiles to a source language.
Citation needed that either of these terms actually existed before 2013.
https://books.google.com/ngrams/graph?content=compiler%2Ctra...
https://trends.google.com/trends/explore?date=all&q=transpil...
https://trends.google.com/trends/explore?date=all&q=transcom...
Your own sources have references in '03, which contradicts that.
But I'll oblige.
Sitting on my shelf is
"XLT86 - 8080 to 8086 Assembly Language Translator, User Guide", dated 1982. (But not the version you can find online, which is September, '81. I'm not quite sure on the release, as the user guides didn't include a revision number).
Here's a quote:
> XLT86·is a Digital Research software product that aids in the translation of 8080 assembly language programs to equivalent 8086 programs.
...
> Unlike other 8086 trans-compilers, XLT86...
> The XLT86 trans-compiler is available for operation under CP/M and MP/M for the 8080, 8085, and Z80...
So, I would say Digital Research coined the term in '81, but their usage suggests that others in that circle would occasionally use the term, or have a passing familiarity with such a term.
Brevity isn't everything. But more importantly, "transpiler" (like "source-to-source compiler") does not say what you are compiling from, and what you are compiling to. In order for the term "transpiler" to be useful, you need to specify those things. Anything you think you imply by using the term is not, in fact, implied.
If you compare the lengths of "JavaScript to Pascal compiler" and "JavaScript to Pascal transpiler", you might be in for a surprise!
It eliminates bytecode compilers and native compilers from the conversation immediately.
> It's not a native compiler, it's a transpiler
If this was said, you wouldn't then ask if it compiled for a VM, or if it could directly produce small binaries.
I wouldn't say the term is completely redundant. Only when you introduce it for the first time.
E.g.
> That's not possible. It's a transpiler. Back to the topic at hand...
> There’s a wealth of tutorials, courses, books, and the like about how to write compilers. But if somebody believes that writing a transpiler isn’t fundamentally the same thing as writing a compiler, it may not occur to them to look at any of that material.
The basic argument is this: "compiler" isn't a term that needs to be limited from transforming a high-level input to a low-level output. Any program which is structured to map an AST to another AST, no matter the relative levels of abstraction, can borrow from many of the principles of modern compiler theory, including using many small passes rather than monolithic rewrites.
At a company I worked for, we compiled a high-level declarative expression language of our own devising into SQL and other back-end representations, including English. Is that a "compiler" as many see it? No. However, thinking about the problem like a compiler problem gave us lots of insights into how to architect our product; it let us draw on an existing wealth of knowledge to make improvements quickly and reliably.