Parser/printer generators

[rikhuijzer]

An utility inside MLIR that is available is the parser/printer generators. For example, MLIR has an utility that can take an assemblyformat expressed in Extended Backus–Naur form (EBNF) such as

`arith.addi` $lhs `,` $rhs

and use that to generate a parser and printer for the arith.addi operation. xrcf could in theory also do that, but I'm very hesitant to implement something like this. The reason is as follows.

Proponents of implementing this will argue that it saves a lot of time. That is indeed true. It is much easier to write a single line string instead of writing multiple lines to do the same.

However, this format alone would not be able to specify any operation. Or at least in MLIR it isn't. This means that the codebase will start to incorporate two ways to define parsers and printers. One via the plain old imperative code and one via these declarative parser/printer generators. I suspect this would lead to multiple issues:

1. Back and forth switching over time when ops can be expressed declaratively, but then new functionality gets added to ops which then cannot be expressed declaratively.
2. Code generation is usually hard to understand.
3. Two ways to solve the same issue means more code has to be maintained. Specifically the code to generate the parsers and printers.
4. Two ways to solve the main issue means that problems in one way can be avoided by using another way (!!). This might be the worst problem of all since it would cause problems in the API design to not be solved.

So my thinking is: whenever I start to look at a parser/printer generator, it's probably a sign that the API should be improved.