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

reusable grammar parser #116

Open
CrockAgile opened this issue Dec 1, 2022 · 2 comments
Open

reusable grammar parser #116

CrockAgile opened this issue Dec 1, 2022 · 2 comments

Comments

@CrockAgile
Copy link
Collaborator

Is your feature request related to a problem? Please describe.

The existing Grammar::parse_input method is useful for parsing input text according to a Grammar. But the current API builds "one use" parsers. This limitation forces some redundant work to be repeated when parsing multiple input texts.

// each of these builds completely new `GrammarMatching` and other parsing tables,
// which are then freed before the next `parse_input`, wasting computation
grammar.parse_input(input_1);
grammar.parse_input(input_2);
grammar.parse_input(input_3);

Describe the solution you'd like

Instead, a single GrammarParser could be available which would reuse parser data efficiently:

let parser = grammar.input_parser();

// common immutable parser data is shared between calls
parser.parse_input(input_1);
parser.parse_input(input_2);
parser.parse_input(input_3);

Describe alternatives you've considered

Maybe this just doesn't matter! I am not sure if this new API would even make much of a performance difference. I am not sure "how much faster" would warrant a new API method. 1% faster? 5% faster? 50% faster?

@Carlyle-Foster
Copy link
Contributor

i don't like this parser API because it implies that if u just want to analyze grammars then the Grammar struct will suffice, but Grammar's are too raw to be of much use in anything, the only upside being that it's easy too append/remove productions to a grammar after it's created because they're just simple lists of Productions.
i think a better idea is too just store the "parser" part (in reality the only part that understands the Grammar semantically) inside the Grammar itself and update it automatically whenever u add/remove a production

@Carlyle-Foster
Copy link
Contributor

we also need the "parser" info to validate Grammars ala #136, which strongly suggests it's useful for more than just parsing

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

No branches or pull requests

2 participants