>> numPersons 2 > I highly recommend not using formats like this, because it's more complex than deterministic context-free. Barely. It avoids the complexity

>> numPersons 2 > I highly recommend not using formats like this, because it's more complex than deterministic context-free. Barely. It avoids the complexity of look-ahead and reallocating growing buffers. > A format that uses s-expressions would be safer and more easier to implement: Trees are unsuitable for almost anything computationally, at least as authoritative representation. Prefer flat. (Widget hierarchies are one of a few counterexamples where the tradeoffs are different). This s-expression you gave is much more complex to parse. Granted, you get parsing as a tree for free. But then you have to go inside the tree and see what's there. That there are two persons per ancestor, etc. Navigating trees is hard. > Is it really "trivial"? Is it actually checking for all of the error conditions? Yes. Yes. Of course. It's the most boring code in the world. Parse numbers, allocate arrays correspondingly, parse each following table in a loop corresponding to the numbers parsed. You can do it all using scanf. Bail out as soon as a bad line comes in. 20 lines. > The benefit of using a parser generator is that those entire classes of bugs are impossible. Yeah. Well, they are not impossible. They are only possible in the parser generator. And interfacing a parser generator is itself not necessarily trivial. Plus, dependencies are a maintenance burden. The other approach is to make the design so simple (like the relational example) to make them (the classes) nonexistent. > You need at least one token of lookahead anyway. Not in the example I gave. > Including the num* fields means the parser needs to remember and manage state. I would hardly call that state. It's an immutable number, initialized in sequential code without real data dependencies (the data dependencies are resolved in the format -- you can not go wrong parsing it).