Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a pitch for adding one or possibly both parsers to the core library. There is nothing in the library that currently lets you do what these do. They are both achieving the same basic goal with a slightly different approach.
They were inspired by this thread in Slack, and I figured the solution might be worth sharing.
For example, the goal from the thread was parsing episode names. This is a simpler example, with a standard format of " - Ep ".
This is actually quite hard to parse right now, since name could contain anything (including "-", digits, etc). The main rule is that it always ends with " - ". For example, "Testing, 1, 2, 3 - a Brief History - Ep 2".
Take
The
Take
parser is provided with two parsers: a 'taker' and a 'terminator'. The results for both are returned as a tuple. Here's how it would parseEpisodeTitle
:Because
Take
's output is a tuple, it's signature looks like this in our example:This is a bit odd, but does generally boil down into single-level tuples thanks to how parsers work in the library.
TakeUpTo
This variant just lets you specify the
terminator
Parser
, and anything before that is returned unmodified.This is a somewhat simpler implementation, but with the key limitation that it doesn't let you have any complex parsing before the terminator. Also, it because it doesn't return the value parsed by the terminator, it can't return that value either, so it has to be parsed again.
For example:
Alternate approaches
I was unable to find anything which would allow parsing in situations like this, but I might have missed something. I attempted to use:
However,
Many
doesn't actively check the terminator - it just checks if the next input matches the terminator once the main parser stops matching. As such, just eats all the text, including the episode details.Anyway, would like to hear your thoughts. Of the two,
Take
is more flexible, but also more complicated, and still has some rough edges I'd like to sand off.