Skip Menu |

This queue is for tickets about the Parse-RecDescent CPAN distribution.

Report information
The Basics
Id: 1279
Status: resolved
Priority: 0/
Queue: Parse-RecDescent

People
Owner: Nobody in particular
Requestors: rho [...] bigpond.net.au
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: (no value)
Fixed in: (no value)



Subject: Slightly inconsistent behaviour using something(s /,/) subrules
In the following program it seems to make a different whether I use $item[1] or $item{rumsti}, although - according to the docs - it should be the same. If I remove the ,'s and use rumsti(s) the behavior of $item[1] and $item{rumsti} is equivalent. Looks like a buglet to me. use Parse::RecDescent; use Data::Dumper; my $parser = new Parse::RecDescent (q { startrule : rumsti(s /,/) { $return = $item[1]; # this returns a list ref of rumstis # $return = $item{rumsti} # this returns only the last rumsti } rumsti : /\w+/ }) || die $@; my $text = 'xxx,yyyy,zzzz ramsti'; print Dumper $parser->startrule(\$text);
I think this ticket can be closed as the subrules are handled now differently. \rho
Thank you for the bug report! The behavior of %item may have changed since this was filed. For this rule: startrule : rumsti(s /,/) $item[1] is equivalent to $item{'rumsti(s)'}. The POD documentation notes that: The results of named subrules are stored in the hash under each subrule's name (including the repetition specifier, if any)... $item{rumsti} happens to be defined because the parser runs the rumsti rule multiple times with the same %item array. This could lead to unexpected behavior with a production like: startrule : rumsti ',' rumsti(s /,/) Where $item{rumsti} takes on the value of the last rumsti to match the 'rumsti(s /,/)' rule, rather than the value of $item[1]. I've noted this in the ToDo, here: https://github.com/jtbraun/Parse-RecDescent/commit/52e30e2bf535ea6e7d25c7de0b7a7bbdcf7a23ed So, the behavior that you've noted is expected and documented, use $item{'rumsti(s)'} to get $item[1] in your example.