Yves wrote:
> First :Try using here docs instead of q{}. They make your grammer
> much cleaner. (and avoid potential issues with \ which i suspect you
> may be suffering).
I will try this if necessary, but it seems unnecessary
right now (things are working fine).
> Second:I wonder if using reserved words as rule names
> is part of the weirdness you describe.
I replaced reserved words with nonreserved, and things
seem to be settled down.
> K, heres a quick little parser I whipped together that does what you
> had in mind. Maybe you can use it to resolve your issues. (Its not
> fully tested, and I had to make up a few things since I didnt have
> the full rules of your grammer handy)
I tried the parser you wrote, with symbol storage, but it
was significantly (30% or so) slower to invoke P::RD
repeatedly on strings than it was to build a
function-based parse tree and reevaluate the tree when
necessary. Furthermore, there was a need to cache the
evaluation results as a function-based parse tree
(because we may be asked to evaluate [A and B]
repeatedly, but intermediate statements may change the
values of A and B). Caching the function-based parse
tree proved much more efficient than invoking P::RD
repeatedly.
You can see the current state of affairs at:
http://savannah.gnu.org/projects/cfperl/
I've had little time lately to work on the project, but
it's certainly been a learning experience to adapt to the
cfengine syntax rules. The top-level grammar still needs
tweaking to accomodate backslash-continued lines, but I
think the class-conditional parsing part of the program
is mostly done. I tested with some large cfengine
configurations and got results that looked good. I
intend cfperl to use P::RD for all parsing, using a
primary parser for top-level parsing, and secondary
parsers for specific purposes. The speed is very decent
in my tests, and besides with cfengine the parsing is
usually not the slow part at all.
Suggestions are welcome, of course.
Thanks
Ted
