My first fifteen compilers • Hacker News Board

Re: My first fifteen compilers

#51

Post by shakna » Sat, Sep 02, 2017, 4:41 PM UTC

sjrd wrote: post #18

shakna wrote: post #13

Earlier quoted context omitted.

> But if somebody believes that writing a transpiler isn’t fundamentally the same thing as writing a compiler, 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

That's unfortunately not my experience. I'm appalled every time someone tells me "But Scala.js is not a compiler, it's a transpiler, since it compiles to JS!" I assume other language users and authors suffer the same kind of comments on a regular basis.

I'm now horrified to learn that you experience is the norm.

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.

Re: My first fifteen compilers

#52

Post by bollu » Sat, Sep 02, 2017, 4:57 PM UTC

TheAceOfHearts wrote: post #9

I'd strongly suggest diving into compilers if you've never studied the subject. Learning a bit on the subject unlocks a ton of incredibly useful skills. That knowledge helps you implement stuff like autocomplete, linters, syntax highlighting, etc. The Super Tiny Compiler [0] is a very gentle introduction to the subject. It's great because it helps you quickly develop an initial mental model. To give an everyday usage…

If I may piggy back on this: I've been writing a tiny optimising compiler in Haskell, to show off the problems and cool ideas that modern compiler toolchains like LLVM have: I'm covering SSA, Scalar evolution, and Register Allocation as a first pass. It's WIP, but [here's the link](https://github.com/bollu/tiny-optimising-compiler)

Re: My first fifteen compilers

#53

Post by tom_mellior » Sat, Sep 02, 2017, 4:58 PM UTC

kqr wrote: post #48

mseebach wrote: post #27

Earlier quoted context omitted.

There's also the etymology, ie. the pre-computing dictionary definition: you compile eg. a list, ie. make something smaller/shorter from a larger input. You also write a book when it's an original work, but another author or editor might take parts of yours and other books and compile an anthology. You might translate a book from one language to another, but that's not considered a compilation.

I've always been under the impression that compile means "put together" rather than "compress".

It does: https://en.wiktionary.org/wiki/compile

Re: My first fifteen compilers

#54

Post by tom_mellior » Sat, Sep 02, 2017, 5:06 PM UTC

shakna wrote: post #50

mseebach wrote: post #44

Earlier quoted context omitted.

So you suggest that transpilers are a subset of compilers, where I suggest that they are disjoint sets. No need for snark.

"Transpiler" is short for "transcompiler". Has been since the 80's. 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…

> "Transpiler" is short for "transcompiler". Has been since the 80's.

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

Re: My first fifteen compilers

#55

Post by tom_mellior » Sat, Sep 02, 2017, 5:18 PM UTC

mhh__ wrote: post #32

I think the nanopass concept - e.g. lots of well defined IRs passing through a pipeline - is a very good idea for teaching, but I'm interested to see how well it performs and also whether, from the programmers perspective, whether this simplifies code or adds unneeded complexity (Specifically, whether they can be optimized quite as well as a big monolithic compiler). I'm currently writing a compiler framework - nothi…

> I'm interested to see how well it performs

Petrashko et al., "Miniphases: Compilation using Modular and Efficient Tree Transformations", PLDI 2017 https://infoscience.epfl.ch/record/228518/files/paper.pdf talks about how they gained a lot of performance by fusing separate passes. So it looks like the nanopass abstraction (like most abstractions) does have a cost in performance. But ease of compiler implementation should in almost all cases be considered more important, I think.

Re: My first fifteen compilers

#56

Post by tom_mellior » Sat, Sep 02, 2017, 5:23 PM UTC

shakna wrote: post #13

kornish wrote: post #2

Favorite quote: > 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 prog…

> But if somebody believes that writing a transpiler isn’t fundamentally the same thing as writing a compiler, 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

> It's shorter than writing "source-to-source compiler"

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!

Re: My first fifteen compilers

#57

Post by andreasgonewild » Sat, Sep 02, 2017, 5:45 PM UTC

SatvikBeri wrote: post #47

As a favor for a friend, I wrote a mini-"compiler" that translated detailed specs for story game scenes into code. I had never done anything similar (my background is more on the Math/Stats side) but I figured hey, what the hell. There were only a few types of possible scenes, so my first approach was to create a data structure for each type of scene that had a method converting it to code. However, this broke badly…

Don't feel bad, tutorials are for when you don't know how to start. If you have a clue how to approach the next step, having a go based on intuition is a superior strategy. Maybe you'll do something stupid, maybe not; either way you learn which means we all win in the long run.

Re: My first fifteen compilers

#58

Post by shakna » Sat, Sep 02, 2017, 5:48 PM UTC

tom_mellior wrote: post #54

shakna wrote: post #50

Earlier quoted context omitted.

"Transpiler" is short for "transcompiler". Has been since the 80's. 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…

> "Transpiler" is short for "transcompiler". Has been since the 80's. 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...

> Citation needed that either of these terms actually existed before 2013.

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.

Re: My first fifteen compilers

#59

Post by sigjuice » Sat, Sep 02, 2017, 5:53 PM UTC

kornish wrote: post #8

sigjuice wrote: post #7

Earlier quoted context omitted.

I'm curious what are the canonical references which state that a compiler does high-level to low-level transformations?

Googling "what is a compiler" returns this: "a program that converts instructions into a machine-code or lower-level form so that they can be read and executed by a computer." So, that's something. 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 equivale…

The Dragon book does not make a distinction between high-level vs low-level output because fundamentally there is none. IMHO it is quite a stretch to claim otherwise because the questionable term "transpiler" exists.

Re: My first fifteen compilers

#60

Post by shakna » Sat, Sep 02, 2017, 5:55 PM UTC

tom_mellior wrote: post #56

shakna wrote: post #13

Earlier quoted context omitted.

> But if somebody believes that writing a transpiler isn’t fundamentally the same thing as writing a compiler, 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

> It's shorter than writing "source-to-source compiler" 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 "JavaSc…

It may lack some specificity, but it makes you look for the terms for "from" and "to".

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