Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My first fifteen compilers

composition.al

Post reply on HN
Print view View original

61–70 of 77 posts

Re: My first fifteen compilers

#61

Post by kqr »

yorwba wrote: post #30
kqr wrote: post #20

Earlier quoted context omitted.

I disagree. I tried that approach for many years but without external input, I could never figure out how to transition from a simple expression language to a proven, working compiler architecture. While large compiler architectures work well for smaller languages, the opposite is not true. I have found it much better to pick a good introductory text and just work through the exercises.

You can turn an interpreter into a compiler by replacing all code that actually does something by code that prints out the code that does it in the target language. It takes a bit to wrap your head around it, and you won't get an optimizing compiler, but a compiler it will be. So your values are no longer values in the interpreter's language, but descriptions in the target language for getting that value. To compile…

I like your comment so please don't interpret my remark as evidence of the contrary. I simply think you misunderstood me.

I didn't mean to say that it's hard to transition from interpreters to compilers, only that I found it hard to transition from interpreting/compiling an arithmetic language to a full structured programming language with general recursion, loops, data structures, variables and so on.

Re: My first fifteen compilers

#62

Post by sigjuice »

nils-m-holm wrote: post #15
eighthnate wrote: post #10

Earlier quoted context omitted.

If people find getting started on a compiler to be a bit too intimidating, one good way to get your feet wet is implementing an interpreter for small subset of a language. Perhaps the basic arithmetic part of adding/multiplying/dividing integers.

People finding compilers intimidating is exactly my audience. :) http://www.t3x.org/t3x/book.html Please excuse the shameless plug!

I have been reading the T3X book and code and I have to say that I am a huge fan of your work. I haven't finished reading it yet, but I have thoroughly enjoyed it so far! I can do successful 'make test' on Linux and NetBSD, but a trivial T3X program seems to misbehave on NetBSD. I look forward to getting to the bottom of it.

A quick question, if you don't mind: why do t.c and t.t differ slightly in the code emitted for t.memcmp, t.copy and t.fill? Thanks!!

Re: My first fifteen compilers

#63

Post by e12e »

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

Webster lists in part:

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

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

Re: My first fifteen compilers

#64

Post by kornish »

sigjuice wrote: post #59
kornish wrote: post #8

Earlier quoted context omitted.

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.

I apologize for not being clearer – I'm not claiming that they're fundamentally different. My original comment, to that point, agrees with the original article's author: compilers are just mappings to and from programs.

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.

Re: My first fifteen compilers

#65

Post by abecedarius »

yorwba wrote: post #41
yorwba wrote: post #30

Earlier quoted context omitted.

You can turn an interpreter into a compiler by replacing all code that actually does something by code that prints out the code that does it in the target language. It takes a bit to wrap your head around it, and you won't get an optimizing compiler, but a compiler it will be. So your values are no longer values in the interpreter's language, but descriptions in the target language for getting that value. To compile…

Since I'm not sure how understandable the explanation was, here is an example, a simple interpreter for a Lisp-like language, using Python lists as the syntax tree. def interpret(state, function_table, expression): function = function_table[expression[0]] return function(state, function_table, *expression[1:]) def interpret_all(state, function_table, expressions): return [interpret(state, function_table, e) for e in…

Somewhat like this but taking it further: https://github.com/darius/toot

Re: My first fifteen compilers

#66

Post by Waterluvian »

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…

You got me thinking. Can a human language like English be defined with an AST? If so, are there examples? If not, why not? I suspect the answer might be, "yes, it's called [this thing I've heard of a thousand times but never considered it to be a language compiler]"

Re: My first fifteen compilers

#67

Post by nils-m-holm »

sigjuice wrote: post #62
nils-m-holm wrote: post #15

Earlier quoted context omitted.

People finding compilers intimidating is exactly my audience. :) http://www.t3x.org/t3x/book.html Please excuse the shameless plug!

I have been reading the T3X book and code and I have to say that I am a huge fan of your work. I haven't finished reading it yet, but I have thoroughly enjoyed it so far! I can do successful 'make test' on Linux and NetBSD, but a trivial T3X program seems to misbehave on NetBSD. I look forward to getting to the bottom of it. A quick question, if you don't mind: why do t.c and t.t differ slightly in the code emitted f…

Thanks! I'm glad you like my work!

The two compilers differ because I stopped applying non-essential modifications to t.c as soon as it was good enough to bootstrap t.t. There are also some edges cases that t.c does not catch. I think it's best to not use it for anything but bootstrapping!

Let me know about that misbehaving NetBSD program when you find out what caused it -- or even if you don't!

Re: My first fifteen compilers

#68

Post by sitkack »

nils-m-holm wrote: post #15
eighthnate wrote: post #10

Earlier quoted context omitted.

If people find getting started on a compiler to be a bit too intimidating, one good way to get your feet wet is implementing an interpreter for small subset of a language. Perhaps the basic arithmetic part of adding/multiplying/dividing integers.

People finding compilers intimidating is exactly my audience. :) http://www.t3x.org/t3x/book.html Please excuse the shameless plug!

I own a number of the Nils Holm books on language implementation and they are all wonderful in a compact, approachable and real-world way that text books are not. A great companion to any programming language course.

Re: My first fifteen compilers

#69

Post by chrisseaton »

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

'Transpiler' has existed since at least 1964, 'communication of algorithms' by Parker-Rhodes.

Re: My first fifteen compilers

#70

Post by TeMPOraL »

shakna wrote: post #51
sjrd wrote: post #18

Earlier quoted context omitted.

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.

Welcome to the webdev world. It keeps inventing new terms for things that already have established terms for decades, probably because it's rare anyone bothers to look back at the decades of stuff not done in JS...
Post reply on HN