The standard term for this kind of compiler is "transpiler", afaik.

Here's the Wikipedia page for such things, which also taught me several other names for them:

https://en.m.wikipedia.org/wiki/Source-to-source_compiler

So, if he had invoked go for you would it be a compiler? Another definition is that it translates a source language into a target language.

What would you call TypeScript’s tsc, which translates TS to JS? Microsoft would say it’s a compiler: https://code.visualstudio.com/docs/typescript/typescript-com...

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

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.

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.

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."

[1] https://dl.acm.org/doi/pdf/10.1145/609784.609818

Who coauthored "The C Programming Language" anyway? Oh right, prof. Kernighan.

https://www.cs.princeton.edu/~bwk/

Eric Schmidt had a career at Sun Microsystems, though he is better known for Google of course.

I worked ~4 layers underneath him when he led Android Wear at Google, and every year or two that happens to me, and it puts a smile on my face. Gotta have love of the game to do this at that level.

IIRC, and man, maybe I'm making it up, but, lore was he always made time on a regular schedule to hack.

Usually 1 layer from the bottom isn't coding so much anymore.

(oddly, I didn't realize he was *CTO* of Stripe until a few months back, when his new thing with Hugo Barra was announced)

I know BASIC is kind of a “bad” language, but there’s something so delightful about it. If we’re plugging TinyBASIC projects that others might find interesting, I made an MMO TinyBASIC REPL the other day: http://10klob.com/

Yeah, I really should have included <> :-)

Fun to see this post from the deep archive get some interest - thanks for reading!

I suspect that this is the more common opinion, especially when the desired outcome is real world use.

Recursive descent is surprisingly ergonomic and clean if one gets the heuristics right. Personally I find it way easier than writing BNF and its derivatives as you quickly get into tricky edge cases, slow performance and opaque errors.

> I write mine all by hand. It's the easiest part of a compiler to write, by far. It's also the least troublesome.

It's also the most annoying if you're writing a new language. You want to iterate on its ideas, but can't do so until you have a parser done.

I've been designing a few language concepts over the past year, and it feels 80% of this time has been writing and debugging parsers; by the time I get to the meat of language design - the shape of its AST, the semantics of it - any small syntactic change means going back to update the lexer and parser stage. Doesn't help that I can't settle on a syntax.

BTW I first started with PEG, which are nice in theory, but I feel the separation of lexing and parsing stage to very helpful to reduce boilerplate (handling whitespace in PEG is obnoxious). Later, I hand-wrote my parsers (in C), but it's gotten so repetitive I've dedicated a weekend to just learning lex/yacc (actually flex/bison). Even if parsers are easy to write, it's good to have higher level tools to reduce the tedium of it.

  > You want to iterate on its ideas, but can't do so until you have a parser done.

In my lifetime parsers have gone from: written by hand with great effort, to: use a parser generator to be sure the grammar is correct and save effort, to: just write by hand because it's not that hard and error reporting, to: just use AI.

I don't think I know any lang devs who don't write their own parser. Beyond just being the easiest part it's also the most fun, and it's the thing that gets you sucked in the first place. If you're using a generator you're missing out.

Another advantage is error recovery code can be made much better. Yacc and lex don't know what common errors are, but you as the language designer knows what the most likely intention of the user was.

Yacc/lex tend to produce generic error messages and do very poorly with error recovery.

Can't pass by without mentioning this amazing post about parsing with error recovery: https://matklad.github.io/2023/05/21/resilient-ll-parsing-tu...

I am probably misunderstanding your requirements but if you are looking for something like regex101 then https://omrelli.ug/nearley-playground/ and https://bnfparser.firebaseapp.com/ although not sure how much 'practical' are they. Googling gives [2], [3], [4].

[2] https://mingodad.github.io/parsertl-playground/playground/ not sure.

[3] https://chrishixon.github.io/chpeg/playground/

[4] https://mdkrajnak.github.io/ebnftest/

If you use something like Antlr (https://www.antlr.org/) it has visualization tools and an online tester (http://lab.antlr.org/). There are also tools for visualizing generic EBNF grammars like this: https://jacquev6.github.io/DrawGrammar/