Live data from Hacker News

Writing a C Compiler: Build a Real Programming Language from Scratch

nostarch.com

151–159 of 159 posts

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#151
post #27

Earlier quoted context omitted.

yacc/bison was used for lex, bc, pcc, gcc, original awk, the bsd pascal compiler, eqn, m4 (!), and many other languages. it's still used for pcc, oawk, mawk, pari/gp, and units. that's just what i have sitting around in my downloads directory and, while we're talking about ocaml, ocaml does use ocamllex and ocamlyacc for its own parser so, while you can certainly do without parser generators, they have very commonly…

I guess I wasn't very clear. I didnt mean to say, as a historical matter, were irrelevant. I meant to say the idea of a parser generator is a solution to a problem that that real world langs don't really have. When writing a programming language, your issue isnt how much time the parser is going to take to write, or how complex it's going to be. The parser is a relatively trivial part of the problem. Due to language…

This still isn't quite correct. Back in the day parsing was a much larger portion of the complexity of a compiler: performance was much more of a concern, as was memory usage. Parser generators were an attempt at helping with that, by allowing programmers to produce more efficient (e.g. table-driven) parsers than what they could have otherwise written by hand. They only really went out of fashion because A) computers got faster and bigger faster than programs got longer, so parsing became less and less of a percentage of total utilization, and B) you can get much better error messages out of recursive-descent parsers.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#152

Earlier quoted context omitted.

I do not agree in the general case. There are very useful DSL compilers which do not consider performance at all, but just compile to a target which does the optimization for them (JVM, LLVM IR or even just C)

Yes but those are called transpilers, right?

There is no fundamental difference between a compiler, transpiler and interpreter.

The techniques employed are very similar

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#153

Earlier quoted context omitted.

Oh, I absolutely see it. My point was that it's necessary. How would you implement the same features Rust and C++ have, without garbage collection, but with simpler syntax?

So you are very careful not to depend on any of their toxic complex features. In the end, better not use them at all. Even plain and simple C99 compilers can be reasonably written by a solo dev, so a motivated small team...

I do depend on their features, and I see the value in doing that.

For example, at $WORK I had to reimplement Apache's mod_rewrite.c in Rust, and I made it 100x faster for our particular use-case.

I could've done that in C as well, sure, but the simplicity of the C language just moves the complexity to the code itself; whereas, with Rust, I whipped out a prototype in just 3 days, and was able to freely pass around pointers to data, with zero allocations, zero copying, and every time it compiled I knew it was guaranteed to be safe.

You can't get that safety in C. You can't get that speed in Java.

You can't do this in any other language that does not have these features. I absolutely agree that the syntax is horrible... but I see no other way to achieve this.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#154

Earlier quoted context omitted.

So you are very careful not to depend on any of their toxic complex features. In the end, better not use them at all. Even plain and simple C99 compilers can be reasonably written by a solo dev, so a motivated small team...

I do depend on their features, and I see the value in doing that. For example, at $WORK I had to reimplement Apache's mod_rewrite.c in Rust, and I made it 100x faster for our particular use-case. I could've done that in C as well, sure, but the simplicity of the C language just moves the complexity to the code itself; whereas, with Rust, I whipped out a prototype in just 3 days, and was able to freely pass around poi…

I severely disagree, this is quite short sighted.

The obscene complexity of the rust language (like c++) makes a toolchain beyond anything reasonable to code alternatives: that reason alone is sufficient to avoid it.

You can have as many "features" you want, the anti-feature of absurd/grotesque syntax complexity _alone_ buries it.

There is nothing more to say or argue about. This is dead simple.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#155

Earlier quoted context omitted.

I do depend on their features, and I see the value in doing that. For example, at $WORK I had to reimplement Apache's mod_rewrite.c in Rust, and I made it 100x faster for our particular use-case. I could've done that in C as well, sure, but the simplicity of the C language just moves the complexity to the code itself; whereas, with Rust, I whipped out a prototype in just 3 days, and was able to freely pass around poi…

I severely disagree, this is quite short sighted. The obscene complexity of the rust language (like c++) makes a toolchain beyond anything reasonable to code alternatives: that reason alone is sufficient to avoid it. You can have as many "features" you want, the anti-feature of absurd/grotesque syntax complexity _alone_ buries it. There is nothing more to say or argue about. This is dead simple.

We will have to agree to disagree, then.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#156

Earlier quoted context omitted.

I severely disagree, this is quite short sighted. The obscene complexity of the rust language (like c++) makes a toolchain beyond anything reasonable to code alternatives: that reason alone is sufficient to avoid it. You can have as many "features" you want, the anti-feature of absurd/grotesque syntax complexity _alone_ buries it. There is nothing more to say or argue about. This is dead simple.

We will have to agree to disagree, then.

Indeed, but with a major difference:

Your side has a significantly higher cost technical dependency than we don't have.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#157

This looks cool, been interested in learning more about compilers since I did the basics in college. Lots of things seem to focus on making interpreters and never make it to the code generation part so its nice to see that this features information about that.

With no disrespect to the book that's the subject of this thread as I haven't read it, but Bob Nystrom's Crafting Interpreter [0] is a fantastic book. It covers all phases in compilation, including both an interpreter and a VM. It's been covered on several threads here over the years [1]. [0]: https://craftinginterpreters.com/ [1]: https://hn.algolia.com/?q=crafting+interpreters

This book covers compiling to assembly whereas Crafting Interpreters only has a bytecode VM implementation. We'll see how good this book is when it drops, but I think that's a worthwhile feature that Crafting Interpreters punted on.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#158
post #113

Earlier quoted context omitted.

I mean these compilers build all these SW stacks, even this very browser I’m using, where are these correctness issues you are talking about?

there are new items in this category every day, but https://blog.cr.yp.to/20240803-clang.html is noteworthy

This is about optimizations affecting timing of cryptographic code, not correctness of computation, the argument for calling this a correctness bug in the compiler is quite weak I think.

Re: Writing a C Compiler: Build a Real Programming Language from Scratch

#159
post #107

Earlier quoted context omitted.

Are you saying your programming languages don’t have a defined grammar?

The parser defines the grammar. This is quite common in mainstream languages -- iirc, only after some years did python get a formal description of a grammar.

> The parser defines the grammar.

But how can you have assurance which grammar it defines, or that it even defines a well-defined grammar?

I’m well aware that some languages don’t bother defining a proper grammar, or define it without having a mechanism to ensure their implementation matches it, but lacking that assurance is exactly the drawback of not using a parser generator.

Post reply on HN