Higher Order Macros in C++

Just to be explicit, here's the kind of code I think you're describing (using some vague Java-esque pseudo-code):

    interface Expression {
      String prettyPrint();
      int evaluate();
    }

    class Plus extends Expression {
      Expression left, right;

      String prettyPrint() {
        return left.prettyPrint() + " + " + right.prettyPrint();
      }

      int evaluate() {
        return left.evaluate() + right.evaluate();
      }
    }

    class Number extends Expression {
      int value;

      String prettyPrint() {
        return value.toString();
      }

      int evaluate() {
        return value;
      }
    }

Here's the AST classes supporting visitor pattern:

    interface Expression {
      String prettyPrint();
      int evaluate();

      T accept<T>(Visitor<T> visitor);
    }

    class Plus extends Expression {
      Expression left, right;

      T accept<T>(Visitor<T> visitor) { return visitor.visitPlus(this); }
    }

    class Number extends Expression {
      int value;

      T accept<T>(Visitor<T> visitor) { return visitor.visitNumber(this); }
    }

    interface Visitor<T> {
      T visitPlus(Plus plus);
      T visitNumber(Number number);
    }

Now we can separate out our concerns. Here's pretty-printing:

    class PrettyPrintVisitor extends Visitor<String> {
      String visitPlus(Plus plus) {
        return plus.left.accept(this) + " + " + plus.right.accept(this);
      }

      String visitNumber(Number number) {
        return number.value.toString();
      }
    }

    class EvalVisitor extends Visitor<int> {
      int visitPlus(Plus plus) {
        return plus.left.accept(this) + plus.right.accept(this);
      }

      int visitNumber(Number number) {
        return number.value;
      }
    }

This is exactly what visitor gives you except replace "function" with "class".

> If someone adds a case, they will just have to add them to half a dozen functions.

They'll have to remember to do that. The visitor pattern makes it a compile error to forget to do that.

I also find the pattern scales up better than doing all of the type tests inside a single enormous function. I like having a separate method per AST type.

The rest comes from my small experience, in college we had a project patching java bytecode on the fly, you could generate correct logic at the bytecode level, but you would lose all the benefit of high level language (typechecking, debugging). One team had this excellent idea to just write the smallest bytecode hook/wrapper that would then call normal Java code.