[robbie-c]

Our SQL is very similar to ClickHouse SQL, in that we used ClickHouse SQL as a starting point as that's what our underlying DB is. We needed to have our own parser so that we could add additional language features on top.

[bonzini]

I think you should clarify that (or whether) while you didn't look at the generated code, you are actually going to adjust it in the future.

How did the two approaches compare in terms of code readability?

[robbie-c]

The previous parser is mostly a declarative grammar file, which is extremely readable. It codegens a C++ parser, which is hard to read. It depends which of those you count as the previous parser's source code!

In the future, we'd make changes by modifying the ANTLR parser first, then using the same approach as in the blog post to get the new parser to parity. We have no plans to get rid of the C++ parser as an oracle!

[bonzini]

Sorry, by two approaches I meant the two parsers generated by the LLM, recursive descent and graph based; not the ANTLR one.

Sort of unexpected that you're keeping the old one as an oracle—but a very good idea for anyone that writes such a complicated parser, indeed!