On making parsers more human-friendly by adding grammar prodctions to make the parser total: https://duriansoftware.com/joe/Constructing-human-grade-parsers.html (allow everything in the AST, but mark errors)
Related Posts
Counter-intuitively, if you're writing a parser for a programming language, you need it to be a total function. As soon as you build IDE tooling, you need ASTs from invalid or incomplete input.
The parser should return (Ast, List<Error>) rather than Result<Ast, Error>.
Today I learnt that `cargo fix` won't fix code with compiler errors by default, but you can override this!
$ cargo fix --broken-code --allow-dirty && cargo clippy --fix --allow-dirty
This incantation does exactly what I wanted :)
I'm adding a += operator to my programming language, because writing `x = x + 1` is tedious.
This opens the tricky design question of which operators should support this. Is += and -= sufficient, or do you expect things like >>= and **= to be available?