Next: Breaking Down Composite Up: Modularity Principle Previous: Isolating the Symbol

Separating Parser from Actions.

A parser's only job is to find structure in a sequence of tokens; it is a separate task from determining the meaning in that structure. Hence, it is beneficial to put the actions in a separate file. This will place parser declarations closer together (because they are not spread out by all the code after a parser declaration). Likewise actions will be moved closer together. It also allows separating checking actions from code generation actions. Incidentally, this will speed compile times because changing an action function will not require rerunning bison and recompiling the generated .c file.

Expr : Expr '+' Expr  { $$ = ExprAction($1,$2,$3); }

In essence, you are separating grammar design decisions from type checking and code generation design decisions. However, they both share the interface of the function. The low-level details of the grammar and type checking are replaced by the decision to have a function that takes in the three parts of the right-hand side, etc.

Functions now called from the parser become the interface of the type checker, code generator, etc. Even if such a component is not easy to represent as a class (e.g., do you really need a ``code generation object''?), it should still have an interface represented by a set of functions, perhaps all stored in a single file.