Live data from Hacker News

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

nostarch.com

111–120 of 159 posts

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

#111
post #57

Earlier quoted context omitted.

it does have a debugger with breakpoints, which even supports time-travel debugging (except on windows obviously), but i've never used it. it even has first-party ide integration: https://ocaml.org/manual/5.2/debugger.html#s:inf-debugger i use debuggers a lot when i'm programming in assembly, and from time to time when i'm programming in c or c++, but in ocaml i've never needed one. it's not that i've never had bugs…

> it does have a debugger with breakpoints, which even supports time-travel debugging (except on windows obviously), but i've never used it. it even has first-party ide integration: https://ocaml.org/manual/5.2/debugger.html#s:inf-debugger 1. I am developing on windows so that's an issue for me and 2. I don't use emacs, I use VScode and I've not been able to get the experimental debugger working for the VScode plugin…

> John Carmack once pointed out that people who come from the game dev and Windows/PC world use debuggers while people from the linux and web dev world tend not to. It seems to be a matter of preference/taste, and I think FP programmers seem to have a distaste for debuggers and graphical debugging/development environments

i think that's true! but i don't think it's purely a matter of preference; it's also a matter of what the ecosystems support well and what you're trying to achieve. lisp is a huge exception to the rule about fp programmers; lisp systems, even including emacs, have extremely strong debugging support. but non-lisp fp languages tend to heavily emphasize static typing, thinking things through ahead of time, and correctness by construction, which reduce the need for debugging. but those are more valuable for writing compilers than for writing games or uis in general, where it's hard to define what counts as 'correct' ahead of time but easy to recognize it when you test it interactively

webdev of course has the problem that you can't stop your http response handler while the browser is waiting for a response. and, often, it's sadly not very concerned with ux. and it's often concerned with operating systems in a way where you have to debug problems after they occur, in part because of the scale of the problems

automated testing is another ecosystem thing that reduces the need for debuggers; to a significant extent it competes with static typing

one of the things i really appreciate about godot is being able to continuously adjust parameters and observe variables in my games as they're running. godot is motherfucking awesome, man. i definitely don't have a distaste for graphical debugging and development environments!

> breakpoints also provide stack traces, so they provide a kind of history as well. I'd rather inspect and interact with a program than dig through thousands of lines of logs (...) print debugging is tedious and requires restarting the program from the beginning whenever you make a change to the source

oh, see, i have programs like grep and emacs that dig through thousands of lines of logs for me. often when i'm debugging from logs i don't run the program at all; i just look at the logs and the source code. sometimes the program is running someplace i can't interact with it—memorably, on some occasions, on a satellite out of range of the groundstation. and usually exceptions on python or java give me a pretty decent stack trace, though other log messages unfortunately don't

there's another ecosystem support issue here—although i've sometimes developed on systems that supported fix-and-continue (cmucl, gforth, squeak, basic-80, godot), python and gcc support it very poorly or not at all. so for me i have to restart the program from the beginning whenever i make a change to the source in any case, whether i'm doing printf debugging or not. godot, again, is a very nice exception to this rule, and incidentally lets me add print debugging to the game while it's running

one of the great things about a breakpoint debugger, from my point of view, is that it makes it possible to add logging after the fact to a running program without editing the source or restarting it

i really appreciate you sharing your experience!

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

#112
post #56
post #29

Earlier quoted context omitted.

Wouldn’t just a simple case of bad code generation render little compiler into a toy one? Repeating others, today’s compilers are really just “optimizing compilers”, there is no room for toying in production environments.

>just a simple case of bad code generation render little compiler into a toy one If you find some time to go through gcc bugzilla you'll find shockingly simple snippets of code that miscompiled (often by optimization passes), with fixes never backported to older versions that production environments like RHEL are using.

I realized with all the rhel systems I’m using, we are never using default toolchains on them. Just use those old systems to run stuff, even newer toolchains.

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

#113
post #104

Earlier quoted context omitted.

if only the gcc and llvm maintainers, and c standard authors, agreed with you

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

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

#114
post #107

Earlier quoted context omitted.

I've created many programming languages. All the ones I finished and were useful did not have grammars that "I wrote".

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

i was puzzled about that too and got even more puzzled when i looked at the languages i could find that he's implemented

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

#115
post #14

So what's different about writing a compiler in 2024 than say 10, 20, or 30 years ago? When I started writing compilers in the 80's and 90's lex/flex and yacc/bison were popular. ANTLR came out but I never had a chance to use it. Everything after lexing and parsing was always hand rolled.

There are actually quite a few changes! The most obvious change you'll see is the use of SSA, which has become the dominant representation in IR starting 25-30 years ago. There's also been an increase in the importance of compiler IRs, and especially the concept of code passing through multiple IRs before reaching machine code. Formal semantics has become more of a thing in the past decade or so. It's now routine tha…

This is a fantastic comment, thanks.

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

#116
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

Eh https://news.ycombinator.com/item?id=41146860

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

#117
post #55

I wonder why there is not the same book for c++... mmmmh... I really wonder... (irony).

It is because c++ has an absurdely and grotesquely massive and complex syntax (like rust...).

Yeah, Rust is the language for people who think C++ is not complex (or hostile) _enough_.

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

#118

I see many comments saying that the book implements the C compiler in ocaml. In the introduction the author states that the book actually uses pseudo code so you are actually free to implement it in any language. The only recommendation is that you use a language with pattern matching because the pseudo code makes heavy use of it. The reference implementation is in ocaml.

Thanks, can you please lemme know which part uses pattern matching? I'd assume mostly in the lexer, but the parser should just be something that consume the tokens and spit out AST. Unless of course it combines the two.

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

#119

I see many comments saying that the book implements the C compiler in ocaml. In the introduction the author states that the book actually uses pseudo code so you are actually free to implement it in any language. The only recommendation is that you use a language with pattern matching because the pseudo code makes heavy use of it. The reference implementation is in ocaml.

Question for HN, pattern matching is defined as “runtime type/value checking”, is that correct?

Is duck typing the pseudo-unsafe alternative? (Not unsafe as in accessing unsafe memory, but as in throwing exceptions if the duck-typed function doesn’t exist on the current type)

Can C handle both?

Coming from a static type system like rust and c#, i’m doing alot of “if this is a duck, duck.quack()” and i’m looking for faster alternatives and less verbosity if possible

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

#120
post #17

How does it compare with N.Wirth's? https://onlinebooks.library.upenn.edu/webbin/book/lookupid?k...

Wirth's book does not implement a "real" programming language. Whatever your thoughts on Oberon and Pascal-like SHOUTCASE languages, it's largely irrelevant. Oberon is arguably a "real" language (and operating system), but Wirth's book does not cover the implementation of Oberon. It covers the implementation of Oberon0, an inarguably toy subset of Oberon. (Actually, "subset" is not even correct.) The example code has also diverged from the book, with Wirth abandoning the strategy described in the book for avoiding redundant initialization of the module static base, among other things.

Aside from that, I encourage everyone who cites Compiler Construction to actually work through the first 10% of the book and then count the number of errata.

Post reply on HN