• Alan Knowles (30/30) Jan 07 2008 Ok - Spent far to much time looking at this yesterday.

Alan Knowles <alan akbkhome.com> writes:

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