Software Project

Top down design and implementation. Scanner, top-down recursive parser, symbol table. The grammar, problems with associativity. Allocation and ownership of objects returned from a function. Function pointers, switch statements.

Programmers are rarely totally satisfied with their code. So after I’ve written the program for this chapter—a simple parser-calculator—I immediately noticed that it could have been done better. Especially the top-level view of the program was not very clear. The nodes of the parsing tree needed access to such components as the Store (the calculator’s "memory"), the symbol table (to print meaningful error messages), maybe even to the function table (to evaluate built-in functions). I could have either made all these objects global and thus known to everybody, or pass references to them to all the nodes of the tree.

The order of construction of these objects was important, so I felt that maybe they should be combined into one high-level object, the Calculator. The temptation to redesign and rewrite the whole program was strong. Maybe after the nth iteration I could come up with something close to the ideal?

Then I decided I shouldn’t do it. Part of making a program is coming up with not-so-good solutions and then improving upon them. I would have cheated if I had come up with the best, and then reverse engineered it to fit the top-down design and implementation process. So here it is—the actual, real-life process of creating a program.