Make parsing of LL(1) or LL(k) parts of the grammar faster

[GoogleCodeExporter]

Possible techniques: predictive parsing, memoization, parallel computations 
(only linear performance improvements though).

Original issue reported on code.google.com by andrey.vlasovskikh on 26 May 2011 at 11:03

• Blocked on: Write tests for LL(1) optimization #22

[GoogleCodeExporter]

Original comment by andrey.vlasovskikh on 26 May 2011 at 11:51

[GoogleCodeExporter]

Slight1y more complicated approach, but you could use the parser structure as a 
definition, and then implement a finite automata behind the scenes. This should 
provide the same speed as more advanced techniques, and keep the simplicity of 
the combinator approach for grammar definitions

Original comment by [email protected] on 22 Nov 2011 at 8:45

[GoogleCodeExporter]

Thanks for your suggestion, Michael!

This idea was one of the drivers behind the development of the 0.9
branch. I've already switched from composition of higher-order parsing
functions to the tree of parser objects (you are referring to it as
the parser structure). Currently my focus is the grammar class
analysis (warnings for non-optimal grammars), other performance
issues, and documentation. If you are interested in the finite
automata parsing approach for funcparserlib, feel free to fork the
codebase :) I could help you with your implementation. Contributions
are very welcome!

Original comment by andrey.vlasovskikh on 22 Nov 2011 at 10:35