Possible RecDescent Bug

Damian,

I seem to be getting $text consumed in a failing
production if that production happens to be the last
production of a rule AND it happens to invoke some
subrules that end up matching some terminal tokens,
thus consuming some text from $text within the failing
production.  If I stick an extra dummy production
after the last one here (eg. <reject>), then it works
OK.  I looked at the pre-compiled grammar.pm file
being produced by RecDescent for this grammar and
noticed something that does not make sense to me.  In
the last few lines of each rule's subroutine, you have
a standard 'unless ( $_matched || defined($return) ||
defined($score) ){' block which will be executed if no
match, or no $return or $score was defined.  I have
confirmed that this block is being executed as
expected when the rule fails.  But inside that block
you have:

$_[1] = $text;  # NOT SURE THIS IS NEEDED

which makes no sense to me why it is there.  I assume
this will propagate changes to $text within this rule
out to the calling rule.  If each subrule ends up
passing up this modified $text to its parent rule, and
eventually a parent rule is reached where a (?) type
repetition specifier is used, that modified $text
value may remain even though the parent rule of the
form 'rule(?)' really did not match any of its
productions.

So the scenario can be stated as:

parent_rule: subrule(?)

subrule: prod1
      |  prod2
      

prod2: 'Hello' '[ ]'

Assume $text starts out as "Hello"

Looks like a bug to me.

Dave Mc


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com