January 07, 2008 Walnut Parser | ||||
---|---|---|---|---|
| ||||
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 |
Copyright © 1999-2021 by the D Language Foundation