dmd

Here's a piece I was proud of 20 years ago. Can you count all the ways it's a steaming pile? https://github.com/dlang/dmd/blob/master/src/dmd/root/outbuf... I've recently fixed a number of its problems, but it's got a ways to go. Am working on it this evening. It needs to be better because earlier today I found a bug enabled by its poor design: https://github.com/dlang/dmd/pull/10462

We've tried various schemes like this with the D compiler. The sweet spot seems to be the current design, where new and possibly buggy/breaking features are introduced with the -preview=feature compiler switch. If it proves out, and users have time to adapt, eventually it becomes the default, and a -revert=feature is there for people who need more time to adapt to it. This has so far been working great. As John Carmack wrote, it enables us to be a little more fearless in introducing new capabilities and putting them on trial. For example, my recent trial implementation of disallowing more than one mutable pointer to the same variable being passed to a function: https://github.com/dlang/dmd/pull/10249 It's hard to tell in advance what effect this will have on the existing D user code base.

I'm still running/maintaining code I originally wrote in the 1980's. https://github.com/dlang/dmd/tree/master/src/dmd/backend

> Arbitrary compile time computation should be separated from the body of the program. Here's some code that initializes an array at compile time with a non-trivial computation: https://github.com/dlang/dmd/blob/master/src/dmd/backend/var... This used to be initialized by a separate program that generated some .d files. It was nice to get rid of that. Even better, if you check the generated object file, there's no trace of the code used to generate the array - just the data for the array.

That's cool, though it doesn't seem to work through a level of indirection. https://d.godbolt.org/z/zkm39N (I don't know much about dlang. I got the compiler flags from googling and happening upon the test case in this PR https://github.com/dlang/dmd/pull/8504/files#diff-bb6a3ed8a5... )

Lexing and parsing are the easiest (by far) parts of writing a compiler. Writing them by hand is very easy, and the code often looks like the grammar. They also tend to be the least buggy parts, I would handwave that maybe 1 in a thousand bugs were in the lexer/parser. Lexer/parser generators are simply not needed and not particularly helpful. Two areas where they are particularly inferior: 1. Error messages. Since the generator doesn't know what you're doing, error messages tend to be generic and very unhelpful to the user. With a hand-built one, context can be supplied to the user in the language of the language(!). Suggestions for corrections for the most common mistakes can be given. 2. Error recovery. Doing this well relies on guessing at what the most likely AST was intended by the user. But a generator can't know that. By the time