Ok - Spent far to much time looking at this yesterday.

I still dont think the approach you are taking is going to work, and is not really going to result in a 'better' parser in any sense

- Maintainable
- Clear to understand / debug.
- Easy to extend (re: EMCAscript4)
- Fast, or even easy to optimize

So I started looking at the alternative. -
This gives you a head start.
http://www.antlr.org/grammar/1153976512034/ecmascriptA3.g

I did start hacking at an alternative to antlr, (yes great waste of time) -
http://www.akbkhome.com/svn/D_Stuff/CrappyParGen/

The more you dig into the syntax, you begin to see that trying to do interpret and parsetime is a like digging a hole and waiting to fall in.
The lookahead stuff is just going to make the interpreting code complex. (is it on/off etc.)

I suspect re-targeting antlr to generate D is probably quite trivial, and a better waste of time ;)

From there, creating opcodes should be pretty trivial....

The resulting code should then be
- Maintable/Readable/Easy to extend etc. as its layed out as a standard Grammer. (anyone who can read grammers can easily work out what's going on)
- Fast: if you can cache the parsing (eg. make it feasible to output opcodes to files ) - and the resulting from antlr should be pretty fast (never as fast as a hard coded interpreter from what I've heard).

Would be nice not to rely on Java to build it though ;)


PS. you need to encapsulate your variables in the parser otherwise the app will not be threadsafe..



Regards
Alan