As the commit message says, the idea is to use tree_evaluator class to
walk the parse tree instead of rvalue methods in the parse tree classes.
To do that requires using a stack in the evaluator class to accumulate
results. Timing the test suite before and after this change show no
significant change in performance.
There are still a number of places where evaluation is performed outside
of the tree_evaluator class, primarily when generating lvalue objects
and when evaluating functions. For these operations, a pointer to the
tree_evaluator object is required and it is either passed to the
functions that need it or accessed globally. Eventually, the global
access should be eliminated.
Once all evaluation is handled in the tree_evaluator class, the parse
tree object should just be a container object that holds a simple
representation of Octave code. At that point, I'd like to work toward a
linear evaluator to replace the current tree walker evaluator. The idea
is to convert the parse tree to a linear list of instructions. Then
evaluation is a loop iteration instead of chasing pointers in a tree.
Having the linear representation may also aid in interfacing with a JIT
compiler. As I recall, Max did something like this already when
prototyping the LLVM JIT compiler (minus the evaluator; he went straight
from the linear represenation to LLVM). So maybe some of what he did
can be reused.