I thought a compiler, with no adjective or caveat, should turn a HLL into machine language. Isn't what this describes—turning BASIC into Go—more accurately described as a "pseudocompiler" or "Go compiler" or somesuch? I know Emacs is always said to have a "bytecode compiler" that processes Elisp code, not a "compiler" per se. Am I mistaken?
This kind of question winds up being the CS equivalent of “is a hotdog a sandwich”. I agree that transpiler is a more accurate term for it and that a hotdog is not a sandwich. But there are lots of languages that start life as compile-to-C things. Many compiled languages today output LLVM IR which is not machine language. Similarly people would probably call javac a compiler, even though it outputs bytecode.
A compiler is a language translator. To me it makes no difference whether it generates machine code (one type of language, machine executable), asm (equivalent language but which needs additional preprocessing into machine code), or some other language (which also needs additional preprocessing into machine code, but the tool for this is another compiler). Or it might output Java bytecode or MSIL, which doesn't even target a real, physical machine at all.
They translate one language into another. The line between compiler/transpiler just doesn't make sense to me.
Let's put it this way: if a program translates code written in a "smarter" language into code written in a "stupider" language, then it is okay to call it a compiler.
If it translates a restricted subset of BASIC into Go, it doesn't really do anything beyond replacing one syntax with another.
"Smarter" and "stupider" are completely subjective terms.
It translates one language into another, while maintaining logical correctness and its original semantics. Some cases are easier to do than others, but it doesn't change the nature of what is being done: language translation.
It isn't as simple as you think. Ex. in basic, the goto statement allows you to jump from anywhere to anywhere. Go has restrictions, such as it may not jump over variables coming into scope (being declared), nor can it jump into another scope, only outwards. So, for starters, this probably needs to scan the BASIC code for variables and hoist everything to the top as well as rewrite any code where it is trying to jump into a deeper scope (ex. jump from the topmost scope of a function into the body of a for loop).
Strictly speaking it's a transpiler, but honestly the delta between the target language (Go) and the source language (BASIC) is very fluffy and wooly, from what I remember from my PL theory days the distinction was always fuzzy enough that people used whatever term felt right to them.
An example off the top of my head — Chicken Scheme (call-cc.org) calls itself a compiler but it's target language is C
The original term for "compiler" was not restricted to compiling down to machine code. From Grace Hopper's paper "The Education of a Computer" (1952)[1]:
Specifications for computer information, a catalogue, compiling routines, and subroutines will be given after adding another level to the block diagram. As Fig. 5 stands the mathematician must still perform all mathematical operations, relegating to the UNIVAC programming and computational operations. However, the computer information delivered by the mathematician no longer deals with numerical quantities as such. It treats of variables and constants in symbolic form together with operations upon them. The insertion of a fourth level of operation is now possible, Fig. 6. Suppose, for example, the mathematician wishes to evaluate a function and its first n derivatives. He sends the information defining the function itself to the UNIVAC. Under control of a "compiling routine of type B", in this case a differentiator, using task routines, the UNIVAC delivers the information necessary to program the computation of the function and its derivatives. From the formula for the function, the UNIVAC derives the formulas of the successive derivatives. This information processed under a compiling routine of Type A yields a program to direct the computation.
Notice the case for two "compilers": Compiler B (differentiator) compiles symbolic notation to another program, that is fed to Compiler A, which produces an executable that does the actual computation.
IMO, a better term for a compiler would have been a "translator."
Indeed. I believe the first use of the word compiler (by Hopper and her team) was to describe "compiling" a bunch of existing machine code subroutines into a whole program, rather than translating one language into another.
A compiler is any program that translates from one language to another (source-to-source, source-to-bytecode, or source-to-machine code), so translating BASIC to Go is indeed a proper compiler, just as GCC translating C to LLVM IR before machine code is still a compiler.
They do, but that article also mixes “transpile” and “compile” often enough that it is near impossible to deduce what different meanings they might ascribe.
