[Eric S. Raymond] > I bit the bullet and hand-rolled a recursive-descent expression parser > for CML2 to replace the Earley-algorithm parser described in my > previous note. It is a little more than twice as fast as the SPARK > code, cutting the CML2 compiler runtime almost exactly in half. > > Sigh. I had been intending to recommend SPARK for the Python standard > library -- as I pointed out in my PC9 paper, it would be the last > piece stock Python needs to be an effective workbench for > minilanguage construction. Unfortunately I'm now convinced Paul > Prescod is right and it's too slow for production use, at least at > version 0.6.1. If all you got out of crafting a one-grammar parser by hand is a measly factor of 2, there's likely a factor of 10 still untouched (wrt "the best" parser generators for restricted grammars, in C). For the all-purpose Earley parser to get that close is really quite an accomplishment! SPARK was written primarily for rapid prototyping, at which it excels (how many times did you change your grammar during development? how much longer would it have taken you to adjust had you needed to rework your RD parser each time?). perhaps-you're-just-praising-it-via-faint-damnation<wink>-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4