I hit that mine too with my first implementation of pass1(), and was a little frustrated that the tree wasn't accepted and I had to refactor.

That said, and to be fair, the grammar for expression and term does define the order the tree should be built in, altough it could be a nice gesture to explicitly state the associativity in the description too.

Very nice kata! Even though it is a very simplistic language, it is cool to have actually witten a (simple, but real) compiler.

It would have been nice to have the Ast classes (C#) provided just like the simulator to easily be able to play with it in your own dev environment (they were easy enough to recreate, but still).

Looking at this kata but haven't tried it yet. That said, the parser would know how many parameters the function needs when it sees its name. Thereby knowing how many expressions to parse to be able give it the parameters it needs. Keeping in mind that an expression would continue to parse as long as it possibly can and still being a valid expression. Thus the parser would parse two subsequent expressions (resolving "2 + 5" and "3" respectively) and give them to the function, evaluate it, and continue on.

It will not stop at just the "2", because "2 + 5" is a valid expression; it will however stop there, because "2 + 5 3" is not a valid expression (as per the grammar).

I hope that makes sense.

Very enjoyable kata! Although it can be solved using way shorter code than I did, it gave me an excuse to go all in and implement some of the common stages in a real compiler; tokenization, parsing into a syntax tree and evaluating it to produce raw "assembly"/command code! I very much enjoyed the complete journey from the syntax highlighting kata all the way to this one.