Thread to evaluate arithmetic expressions

Question

I'm trying to write a program that evalutaes arithmetic expression concurrently using Java concurency primitives. The idea behind the threading is to avoid multiple evaluations of common subexpression. I have attached the code that I have written so far but was hoping someone could offer me a hand with the evaluate() and run() methods contained at the end of the program. Thanks.
public class Example {
     public static void main(String[] args) {
          BinaryOp plus = new BinaryOp() {
               public int apply(int n1, int n2) {
                    return n1 + n2;
          BinaryOp times = new BinaryOp() {
               public int apply(int n1, int n2) {
                    return n1 * n2;
          Arith e1 = new Operator(plus, new Number(4), new Number(5));
          Arith e2 = new Operator(plus,new Operator(times, new Number(3), e1),
               new Operator(plus, e1, new Number(6)));
          Arith e3 = new Operator(times, e2, e2);
          System.out.println(e3.evaluate());
interface BinaryOp {
     // An operator that can be applied to two numbers
     int apply(int n1, int n2);
interface Arith {
     // An arithmetic expression that can be evaluated.
     int evaluate();
class Number implements Arith {
     private int n;
     Number(int n) {
          this.n = n;
     public int evaluate() { // A number evaluates to itself.
          return n;
class Operator implements Arith, Runnable {
     private BinaryOp op;
     private Arith e1;
     private Arith e2;
     private boolean done = false;
     private int result = 0; // holds the result of previous evaluation
     Operator(BinaryOp op, Arith e1, Arith e2) {
          this.op = op;
          this.e1 = e1;
          this.e2 = e2;
          (new Thread(this)).start();
     public int evaluate() {
     public void run() {
}

Answer 1

I'm trying to write a program that evalutaes arithmetic expression
concurrently using Java concurency primitives. The idea behind the
threading is to avoid multiple evaluations of common subexpression. Interesting ... the main problem however is to find those common
subexpressions. Most of the evaluation of those common subexpressions
can be done in the parse/compile phase though, effectively elliminating
the need for threads, e.g. (foo+bar)-(foo+bar) can be deduced to be
equal to zero if both 'foo' and 'bar' happen to referential transparent,
i.e. they don't have side effects.
What you're doing now is just starting a new thread for every binary operator.
This is, most likely, not what you want. The strategy of what thread to
start for which subexpression must have layed out the sequence of
threads to start before actual evaluation is started (also see above).
kind regards,
Jos