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

sep_by(any(), char(',')) #52

Closed
Qard opened this issue Dec 6, 2015 · 7 comments
Closed

sep_by(any(), char(',')) #52

Qard opened this issue Dec 6, 2015 · 7 comments

Comments

@Qard
Copy link

Qard commented Dec 6, 2015

Is there an uncomplicated way to achieve a parser that does sep_by(any(), char(','))?

I currently have something like sep_by(parser(other), char(',')) where other is a separate parser that just matches any(), but that blows right through every instance of , due to the any() parser.

What I want is something that works the same as sep_by, but parsing the separator takes precedence over parsing the separated values. I don't want the other parser to need to be aware of the context in which it is used.

@Marwes
Copy link
Owner

Marwes commented Dec 6, 2015

Not really from what I can think of, you may want to make a custom "sep_by" parser to handle that.

With the current parsers combine provides though I think you might be able to hack around it with the recently added look_ahead parser though.

sep_by(look_ahead(satisfy(|c| c != ',')).with(parser(other)), char(','))

It looks a bit weird but I think it should do what you want (might be some edge case I haven't considered though).

EDIT: No that will not actually work. I am not sure that what you want is actually possible in combine.

@Marwes
Copy link
Owner

Marwes commented Dec 6, 2015

I don't believe that what you want is easily possible with combine which uses recursive descent for parsing. If your other parser is able to successfully consume a ',' at some point during its parsing it needs to be "aware" in some way that the sep_by parser should take precedence which is at odds with combine's model in which each parser is unaware of where it is used.

@Qard
Copy link
Author

Qard commented Dec 6, 2015

I don't think it's necessarily at odds. The parser just needs to store and consume all tokens until it reaches the tokens that get consumed by the separator parser, then feed everything up to that point into the item parser. It's kind of cheating at LALR, but it might work okay.

@Marwes
Copy link
Owner

Marwes commented Dec 6, 2015

It might work but if you have a grammar which requires you to work around it like that it might be better to use a more powerful tool/library instead (lalrpop comes to mind but I don't know how mature it is yet).

@Marwes
Copy link
Owner

Marwes commented Feb 2, 2016

Closing. Feel free to reopen if there is more to be said on this topic

@Marwes Marwes closed this as completed Feb 2, 2016
@PSeitz
Copy link

PSeitz commented Sep 8, 2018

When searching for precendence in this repo, this is the only result, but it seems the combine_language crate enables this? (https://docs.rs/combine-language/3.0.1/combine_language/struct.Assoc.html#structfield.precedence)

@Marwes
Copy link
Owner

Marwes commented Sep 8, 2018

That's a slightly different meaning of precedence but yes. If you need to parse one is expressions, combine-language supports that.

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

3 participants