Question: There is a question in the second chapter of the book that I'm unable to solve, and unfortunately [algorist.com](https://algorist.com) does not provide a rigorous enough solution, or maybe I can't quite understand it.
Here is the question:

[![enter image description here](https://i.stack.imgur.com/5s3k8.png)](https://i.stack.imgur.com/5s3k8.png)

I've noticed the sums of rows are the powers of 3, and it's intuitively obvious that the sums of rows are multiples of 3, however I can't prove that they are **powers** of 3.

Any help would be much appreciated.

*The Algorithm Design Manual* from *Steven S. Skiena*
You can get it from [here](https://rads.stackoverflow.com/amzn/click/com/1849967202).

Also [here](https://algorist.com/algowiki/index.php/2.37) is the solution I found on algorist.com .

Answer: 
Both work, so how you do it is up to you. But there are a couple of reasons to consider doing it during a post-parse analysis:

1. While it is certainly possible to define two different types of `block`, one in which `break` is legal and the other one in which it isn't, the result is a lot of duplication in the grammar, and a certain complication because you have to allow `break` inside blocks which are themselves contained inside a looping construct. If you allow compound statements without explicit blocks, like `if (condition) break;`, then you also need to define different `if` statements, etc. This rapidly gets out of hand unless you have a tagged formalism like that used in ECMAScript.
2. Detecting the error in a post-parse scan will allow you to produce better error messages. Rather than just presenting the user with some kind of `syntax error` message (which might be "unexpected token 'break'"), you can actually provide a meaningful error message like "'break' statement cannot be used outside of a loop."
You could do this purely in syntax - you’d have a grammar with two non-terminals for “statement that can contain a break” and one for “statement that may not contain a break”. You duplicate the size of the grammar, making it a right pain.

When you parse a break statement you need semantics anyway to determine what exactly it breaks from, since you may have nested loops and switch statements. Detecting that it has nothing to break from is a tiny part of that, so semantically it’s quite simple. You will save yourself some headache by doing this check in your semantics.

Of course you will use the syntax to prevent things like “x = break + 1;”.