In fact, that often even bleeds forward into the front end. For a compiler, you're in this state of actively discarding information. Comments? Don't even lex them. Variable names? Just de Bruijn index them.
FYI, for anyone thinking about writing a production compiler front-end, don't do this, it's a terrible idea.
Re:Killing Off Wasabi – Part 2
by munificent on Friday July 17, 2015 @12:00PM
(#9903363)
I think the important bit is to not throw that information away until after you've reported any compile errors. Once you know the code is valid, you can discard that stuff (unless you need it to generate debugging information).
Oh, yes, that's fine. Although by that point you've kind of already spent the time, so it's not going to gain you much by throwing it out.
Really?
> 1. You may need to inspect the ___piler output to find bugs in it.
The set of people who are debugging a C++ compiler by looking at its machine code output is vanishingly small compared to the number of regular working C++ programmers.
> 2. A user may read the ___piler output to better understand the semantics of the source language. "Oh, ___ in CoffeeScript means ___ in JS!".
I'm not aware of anyone who learned C++'s high level semantics by seeing what machine code they are compiled to. Sure, there are a couple of corner cases where you might want to dig into the details of how something like vtables or calling conventions are implemented. But no one I know says, "Hmm, what does 'protected' mean? Let me look at the ASM and see."
But that is exactly how people learn CoffeeScript. Look right on the page: http://coffeescript.org/
> 3. The user will need to debug their program. Unless you have very sophisticated debugging infrastructure (hint: source maps are not good enough), then that means they will be stepping through the ___piler output, not the original source.
Fortunately, we do have very sophisticated debuggers for C++. A handful of real pros may also step through the assembly on rare occasions, but most working C++ programmers never do and never need to.
This is simply not the case for other transpiled langauges. There is no such thing as a "CoffeeScript debugger".
> 4. A user may end up discarding the original source and hand-maintaining the ___piled output as the new source of truth.
Heaven help you if you have to do this with the machine code of your C++ compiler. I've heard horror stories of teams that had to do this after losing the original source, but there's a reason we consider those horror stories. I've never heard of anyone doing this deliberately or considering it a feature.
> We don't run around giving them all names.
"Link time optimization", "dead code elimination", "global value numbering", "constant folding", "common subexpression elimination", "static single assignment form", "continuation-passing style", ...
> For instance, you're always worried about the mapping of the source to the target language... that's hardly special to Coffeescript. How could you possibly create a good compiler without thinking about that?
Your C++ compiler writer is never thinking, "How can I make this for() loop look like a for loop in assembly?" Or "How can I maintain this local variable name?"
In fact, they are often doing the opposite: "How can I lower this for loop to a more primitive control flow graph so I can optimize it?" Or "How can I eliminate this local variable entirely if it's never read?"
But that kind of stuff is exactly what a transpiler writer is trying to maintain.
> In the meantime, the cognitive damage of people thinking these are somehow different skillsets is bad.
I don't think having a different term for transpilers causes any cognitive damage. If anything, the name is associated with "lightweight compilers" like CoffeeScript which are more approachable to newcomers than "real" compilers like you learn about in the dragon book.
> You'll find you've automatically learned how to write transpilers too, without a single additional lesson.
I've written both, and I think there is actually quite a bit of difference between the two. Sure, the parsing is the same. But the way you approach code gen is very different between a compiler and a transpiler.
In fact, that often even bleeds forward into the front end. For a compiler, you're in this state of actively discarding information. Comments? Don't even lex them. Variable names? Just de Bruijn index them.
With a transpiler, all of that is precious data that you have to carefully pipe through to make the output code as readable as possible.
I don't think any of this is rocket science, and I definitely encourage more people to learn how to do this. If nothing else, it's tons of fun. But transpilers are different from compilers.
They share a lot of techniques, but they have different goals, scope, and requirements. Having a different word for that doesn't seem bad to me.
Honestly, if you want to talk about confusing PL terms, how about "interpreter" and "virtual machine". Now those are ones that cause real confusion.