+/**
+ * Parses a stream of lexed tokens into a tree of CompiledFunction's.
+ *
+
+ * There are three kinds of things we parse: blocks, statements,
+ * expressions. Expressions are a special type of statement that
+ * evaluates to a value (for example, "break" is not an expression,
+ * but "3+2" is). AssignmentTargets are a special kind of expression
+ * that can be 'put' to (for example, "foo()" is not an
+ * assignmentTarget, but "foo[7]" is). FIXME.
+
+ *
+ * Technically it would be a better design for this class to build an
+ * intermediate parse tree and use that to emit bytecode. Here's the
+ * tradeoff:
+ *
+ * Advantages of building a parse tree:
+ * - easier to apply optimizations
+ * - would let us handle more sophisticated languages than JavaScript
+ *
+ * Advantages of leaving out the parse tree
+ * - faster compilation
+ * - less load on the garbage collector
+ * - much simpler code, easier to understand
+ * - less error-prone
+ *
+ * Fortunately JS is such a simple language that we can get away with
+ * the half-assed approach and still produce a working, complete
+ * compiler.
+ *
+ * The bytecode language emitted doesn't really cause any appreciable
+ * semantic loss, and is itself a parseable language very similar to
+ * Forth or a postfix variant of LISP. This means that the bytecode
+ * can be transformed into a parse tree, which can be manipulated.
+ * So if we ever want to add an optimizer, it could easily be done by
+ * producing a parse tree from the bytecode, optimizing that tree,
+ * and then re-emitting the bytecode. The parse tree node class
+ * would also be much simpler since the bytecode language has so few
+ * operators.
+ *
+ * Actually, the above paragraph is slightly inaccurate -- there are
+ * places where we push a value and then perform an arbitrary number
+ * of operations using it before popping it; this doesn't parse well.
+ * But these cases are clearly marked and easy to change if we do
+ * need to move to a parse tree format.
+ */