@clickhouse/rowbinary: when your library is also a parser compiler
4 points by peter-leonov
4 points by peter-leonov
I used to do the "proper" parser generation work some time ago and found out that a good enough generator has to make so many opinionated decisions that it starts to feel like writing a… small natural language translation level nuanced machine. Thus the attempt to use modern coding LLMs to please each and every picky user.
How should users test the generated code? It could be nice to provide a deterministic compiler for producing fast-check arbitraries (which shouldn’t be as hard as generating a parser?) for generating sample input data. This would open up the option of using property-based tests to check things like floating point bounds errors or data round-tripping.
Fair point.
I've got a little piece on this for my other parser generator: https://lobste.rs/s/nowty1/generating_test_values_using_javascript
But this time I fully rely on LLMs to generate as many roundtrip tests as one desires. Even Sonnet does it in bulk for fraction of a penny.
Don't get me wrong, I love parsers and generators and all the jazz. There is still good time for them in today LLM overwhelmed world. The library, actually, has a built-in ClickHouse type parser and AST-to-reader micro-compiler which an LLM can use for testing. It's just sort of trivial for LLMs to handle both, just use two fresh context windows or models.