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

How to Write Your Own Compiler (2009)

staff.polito.it

Post reply on HN
Print view View original

31–40 of 43 posts

Re: How to Write Your Own Compiler (2009)

#31

Post by vidarh »

andreasgonewild wrote: post #14
vidarh wrote: post #13

Earlier quoted context omitted.

Forth is one of those things that always fascinates me but ultimately always ends up feeling too hard to read. Snabel looks like an interesting experiment in that regard..

Lisp and Forth, everyone gets that reaction on first contact; the real problem is that most popular languages look the same these days. Popularity has very little to do with earning it. And it's getting worse with more and more crapscript lately. I'm not very much into dogmatics and orthodoxy, Forth wasn't the final answer to anything. Nothing ever is. Implementing the same thing over and over again doesn't make sens…

I've spent a lot of time over the years trying to get used to Lispy and Forth-like languages, and the syntax is a much greater barrier than you think.

Most languages look pretty much the same because we do have half a century of experience with what people get comfortable with. There's further centuries of experience with what people find readable in natural language. People seem to infer a lot more information from layout and structure than some seem to think.

But there is a split there between those who are fine with dense syntax and those who are not. Lisp, Forth, and many functional languages fall in a category that tend to be popular with people who also e.g. find mathematical notation straightforward and are happy to decipher symbol after symbol.

But for many of us, being able to instantly get an overview is a visual process that requires more distinct syntax. I can remember pages of code I saw 20-30 years ago by the overall shape of he code, and layout, and even the font, but if I'm asked to recall code by a sequence of tokens I had to read token by token, I'd draw a blank over code I saw days ago.

That's why you see languages like e.g. Ruby, that in themselves bring very little new on the semantics side, but that popularise ideas from other languages (e.g. Smalltalk, Self for Ruby, along with a lot of syntactical baggage from Perl).

In recent years a lot of ideas have been lifted from Lisp, but some of them are linked quite closely to Lisps syntax. We've started seeing languages tackle this, but it's still a tricky balance to get right.

But I think Forth lacks a language that can do this for it. Retaining the ideas of Forth while making it readable to a bigger audience seems like a hard problem, but it's been (reasonably well) tackled for Smalltalk and Lisp. That's what piqued my interested with your experiment.

Re: How to Write Your Own Compiler (2009)

#32

Post by zeveb »

vidarh wrote: post #31
andreasgonewild wrote: post #14

Earlier quoted context omitted.

Lisp and Forth, everyone gets that reaction on first contact; the real problem is that most popular languages look the same these days. Popularity has very little to do with earning it. And it's getting worse with more and more crapscript lately. I'm not very much into dogmatics and orthodoxy, Forth wasn't the final answer to anything. Nothing ever is. Implementing the same thing over and over again doesn't make sens…

I've spent a lot of time over the years trying to get used to Lispy and Forth-like languages, and the syntax is a much greater barrier than you think. Most languages look pretty much the same because we do have half a century of experience with what people get comfortable with. There's further centuries of experience with what people find readable in natural language. People seem to infer a lot more information from…

> Most languages look pretty much the same because we do have half a century of experience with what people get comfortable with.

I think it's more about familiarity rather than any inherent quality of the syntax itself.

> But for many of us, being able to instantly get an overview is a visual process that requires more distinct syntax.

I think colour and shape can go a long way here, too — and that applies to both Forth & Lisp.

Re: How to Write Your Own Compiler (2009)

#33

Post by andreasgonewild »

vidarh wrote: post #31
andreasgonewild wrote: post #14

Earlier quoted context omitted.

Lisp and Forth, everyone gets that reaction on first contact; the real problem is that most popular languages look the same these days. Popularity has very little to do with earning it. And it's getting worse with more and more crapscript lately. I'm not very much into dogmatics and orthodoxy, Forth wasn't the final answer to anything. Nothing ever is. Implementing the same thing over and over again doesn't make sens…

I've spent a lot of time over the years trying to get used to Lispy and Forth-like languages, and the syntax is a much greater barrier than you think. Most languages look pretty much the same because we do have half a century of experience with what people get comfortable with. There's further centuries of experience with what people find readable in natural language. People seem to infer a lot more information from…

I guess you could say we've had similar experiences, I wouldn't be this motivated to find another way if I thought Lisp or Forth was the final answer either. Or Smalltalk, I was really excited about Strongtalk for a while. I've had this gut feeling for a long, long time that it's quite possible to add more structure without taking away the power; and doing it in Forth proves the point.

Re: How to Write Your Own Compiler (2009)

#34

Post by kqr »

jcranberry wrote: post #24
neurotrace wrote: post #22

Earlier quoted context omitted.

The dragon book is very informative but is harder to parse (ha) than many other compiler books. People should definitely read it, it just might be hard to read as a "My First Compiler" book.

I started reading it a while ago when I wanted to properly learn compilers. I actually thought it was very readable.

I must agree. It may be that you and I lean more toward the theoretical side and want more of a "grounds up" material (a chapter about transforming regexes to state machines? seriously?) than a "here's what to do to get it done by next thursday" book.

Re: How to Write Your Own Compiler (2009)

#35

Post by andreasgonewild »

zeveb wrote: post #32
vidarh wrote: post #31

Earlier quoted context omitted.

I've spent a lot of time over the years trying to get used to Lispy and Forth-like languages, and the syntax is a much greater barrier than you think. Most languages look pretty much the same because we do have half a century of experience with what people get comfortable with. There's further centuries of experience with what people find readable in natural language. People seem to infer a lot more information from…

> Most languages look pretty much the same because we do have half a century of experience with what people get comfortable with. I think it's more about familiarity rather than any inherent quality of the syntax itself. > But for many of us, being able to instantly get an overview is a visual process that requires more distinct syntax. I think colour and shape can go a long way here, too — and that applies to both F…

Or choice of symbols and identifiers. People love to bash Perl, but Larry is definitely on to something when it comes to names and symbols, however flawed/misused the implementation in Perl may be; I feel like we're chasing the same ghosts.

An example is Snabels use of "|" for resetting the stack, "_" for dropping the top and "(..)" for grouping modifications; it smells a tiny bit like Perl in that it's not afraid of using what's available to get the wanted experience, but has a dramatic effect on code shape compared to regular mumble-Forth.

Re: How to Write Your Own Compiler (2009)

#36

Post by jcranberry »

kqr wrote: post #34
jcranberry wrote: post #24

Earlier quoted context omitted.

I started reading it a while ago when I wanted to properly learn compilers. I actually thought it was very readable.

I must agree. It may be that you and I lean more toward the theoretical side and want more of a "grounds up" material (a chapter about transforming regexes to state machines? seriously?) than a "here's what to do to get it done by next thursday" book.

LOL. Anyone attempting to build a compiler by next thursday is in for a rude awakening.

In any case you're probably right, given that I like math and (so far) prefer algebra to analysis or applied mathematics.

Re: How to Write Your Own Compiler (2009)

#37

Post by chubot »

bollu wrote: post #26

Shameless plug: I've been writing a series that's WIP about writing a tiny optimising compiler - https://github.com/bollu/tiny-optimising-compiler . It tries to model as much as possible, and the aim is to show off the power that modern compiler ideas bring: SSA and polyhedral compilation.

This looks cool, thanks for pointing it out.

I'm somewhat familiar witih SSA, but I don't know anything about polyhedral compilation. What does it buy you? Is there a concise intro you could point to?

(I thought I had heard someone say it makes your compiler slower for marginal benefit, but they/I could be wrong about that.)

FWIW I found this introduction to the new Go SSA back end pretty useful as an overview:

https://www.youtube.com/watch?v=uTMvKVma5ms

One thing that was interesting is that they seemed to have an LLVM TableGen-like "rules" DSL for both architecture-independent and -dependent optimizations / code gen.

I don't think polyhedral compilation was mentioned and I don't think they use it.

Re: How to Write Your Own Compiler (2009)

#38

Post by Athas »

js2 wrote: post #30
Athas wrote: post #25

Earlier quoted context omitted.

While there are some good bits in the dragon book, some of its advice on the engineering of a compiler is pretty dated. For example, most of the parsing chapter(s) seem to have the notion that there is a single (global?) symbol table to which tokens and various other things refer, and which is gradually refined and updated throughout compilation. I think that may have been a widespread design once, but it's a bizarre…

Thank you for the detailed reply. It's been years since my compilers class. I gather no one still uses lex and yacc either? To give you an idea how out of date I am in this area, when I took my compilers class we used http://www.cs.princeton.edu/~appel/modern/java/CUP/manual.ht... for much of the course work. And I've had surprisngly little need during my career for this subject area.

Lex and yacc are still frequently used (alongside similar tools like ANTLR). However, most production compilers use hand-written parsers because it permits better error messages and support for partial parses. The latter is useful for e.g. IDEs, where the code is often not entirely syntax-correct.

Re: How to Write Your Own Compiler (2009)

#39

Post by robertbaruch »

pjmlp wrote: post #7
jonsen wrote: post #6

Earlier quoted context omitted.

Also Brinch Hansen on Pascal Compilers : https://www.amazon.com/Brinch-Hansen-Pascal-Compilers/dp/013...

> 1 New from $3,000.00 Uau! I should take care of my old books.

Haha, don't forget there has to be a seller AND a buyer for a price to hold true.

Re: How to Write Your Own Compiler (2009)

#40

Post by kazinator »

robertbaruch wrote: post #39
pjmlp wrote: post #7

Earlier quoted context omitted.

> 1 New from $3,000.00 Uau! I should take care of my old books.

Haha, don't forget there has to be a seller AND a buyer for a price to hold true.

There also has to be volume for a price to hold true. Even if someone buys that one for $3000, that doesn't mean it's the price if it only happens once.
Post reply on HN