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

add the ability to have subslice parser combinators #242

Closed

Conversation

herkhinah
Copy link

I want to be able to implement parser combinators where the second parser parses only the input slice the previous parser has parsed. E.g. an AndIs implementation where the second parser is limited to the input the first parser has parsed.

As I'm making changes that feel more to the core than my previous I wanted to ask if I'm on the right track implementation wise and if such functionality would be welcome.

I've added a (badly named) trait Slice that is a SliceInput with the additional constraint Self = SliceInput::Slice. The use case is for parser combinators like the one described above so that both parser can have the same error type. Then there is the with_subslice function that limits the input in InputRef for the passed closure to the passed range.

let mut input = self.slice(range);
let mut marker = Marker {
pos: 0,
offset: input.start(),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to be a bit careful here: offset is used for prioritising errors, and this effectively ends up lying to the rest of the crate about the offset of an error, which could have strange ramifications.

@zesterer
Copy link
Owner

zesterer commented Jan 4, 2023

I think I'm a bit uncomfortable about merging this until we have a specific use-case for it (such as AndIs, as you say). It's likely that this code will need changing a little for such a case anyway, so I'd prefer to merge it along with code that actually uses it and hence can be tested.

@herkhinah
Copy link
Author

Yes, it was a hack for a use case that I don't have anymore.

@herkhinah herkhinah closed this Jan 5, 2023
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

Successfully merging this pull request may close these issues.

None yet

2 participants