The philosophy is that it is easy to convert from Concrete -> Aggregate syntax, and also from Aggregate -> Abstract. So at those 3 stages, we do scans for rules that are defined.
For people playing at home:
Concrete Syntax: parse tree with whitespace are comments preserved (think InputForm)
Aggregate Syntax: all whitespace and comments have been stripped.
Abstract Syntax: nodes are transformed into more abstract forms (think FullForm)
Most rules will be for Abstract syntax.
You can ask yourself: Does the difference between 1+2 and Plus[1,2] matter for my rule? If no, then use Abstract Syntax. If yes, then ask: would whitespace affect the rule? If no, then use Aggregate Syntax. Otherwise use Concrete Syntax.
It should be noted: I am also thinking of the best way to represent a level lower than Concrete Syntax, working directly with tokens. This would be where a rule for ;; at the end of a line would be. It would be wrong to have the rule ";; at the end of a line" as Concrete Syntax, because it is hard to check "end of line" in a tree structure. But with a list of tokens, just need to check ;; token is next to \n token. Maybe it will be called TokenRules or something.
