Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid creating single-element Perl arrays when the rule body unambiguously contains only one capturing subrule #33

Open
agentzh opened this issue Mar 29, 2015 · 3 comments

Comments

@agentzh
Copy link
Contributor

agentzh commented Mar 29, 2015

Often, a rule's production contains only one capturing subrule, like this:

foo: / a / bar / b /

Here only bar is a capturing subrule while neither / a / nor / b / do.

Hopefully the pegex engine can recognize such productions at compile time and avoid always creating a single-element Perl array for every got_foo() call. This way we can not only save some runtime overhead and can also save customized got_foo function definitions in the user receiver class. For example, I've found myself keep writing quite a lot of boring stubs for such productions like below:

sub got_foo() {
    my ($self, $list) = @_;
    $list->[0];
}
@ingydotnet
Copy link
Collaborator

@agentzh, can you please finish this out by providing a rule for bar and some
parsable input. Again if you can use this one-liner form, it is most helpful
for reproduction:

perl -MXXX -MPegex -e 'XXX pegex($grammar)->parse($input)'

@ingydotnet
Copy link
Collaborator

OK. I think I get it.

Basically:

a: b c d

is:

a: (b c d)1

Since there is a group, it adds the array.

Pegex isn't smart enough yet to know when an array has captures.

There's a ton of permutations and optimizations to consider. I'll start writing
a test suite for this tomorrow.

@agentzh
Copy link
Contributor Author

agentzh commented Mar 30, 2015

@ingydotnet Great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants