Useful RE patterns (was: Variable Interpolation - status of PEP215)

[Mike C. Fletcher]

Pekka Niiranen wrote:
 > Please make also example of recursive decent parser, for example LL(k)
 >
 > -pekka-
...

Hmm, it would seem a bit out-of-scope to create an example of a 
hand-coded recursive descent parser for a parser-generator system. 
After all, the idea is to _avoid_ writing your own recursive descent 
parsers as much as possible :) ;) .

As for LL(k), I've never been able to determine what the grammar 
classification of SimpleParse grammars is.  The algorithm doesn't seem 
to match closely enough with the standard parsing algos (which all seem 
to be tokeniser based).  If you were to just lex the file with your 
generated grammar, then your post-processing functions could use 
whatever algo they wanted (even Earley (sp?)), but then you would lose 
much of the speed of the C engine, so you'd likely want something where 
you match all non-ambiguous grammar constructs with the generated 
system, and use Earley (or whatever) for the ambiguous or more 
context-sensitive stuff.  That said, I normally let the C engine do all 
the parsing, but I deal with simple, data-format-style grammars most of 
the time.

Of course, if someone with a yen for traditional parsers wanted to, they 
could write a parser-generator of their own to fit into the system in a 
few hours.  They'd basically just create a new objectgenerator.py for 
their system, a Parser-sub-class to do the transformation from ebnf to 
their new generators (such as seen in simpleparsegrammar.py) and create 
their own sub-class of the "Parser" class to use that grammar by default.

Aside: I'm wanting look at SPARK's code after the 2.0 release of 
SimpleParse and see what would be necessary to auto-generate SPARK 
parsers from EBNFs (then see about making it an optional generation 
option for SimpleParse).  Anyone who wanted to beat me to the punch 
would be welcome :) .

Anyway, to work, to work, it's off to work I go...
Enjoy,
Mike