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

feat: Add output_stream/with_output_stream to Parser #233

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

martinohmann
Copy link
Contributor

@martinohmann martinohmann commented Apr 17, 2023

This is a draft implementation to solve #231

As noted in the initial issue, I'm not too settled on the naming here, there are other alternatives like recognize_stream/with_recognized_stream.

If you think the idea is worth pursuing further, I can also add some tests/examples for use cases like the following:

  • use Parser::output_stream().and_then(..) to map another parser over the Stream.
  • use Parser::with_output_stream().map(...) to access/update the state in a Stateful in the map closure.

Happy to hear your thoughts on this.

@martinohmann
Copy link
Contributor Author

@epage any opinion about this?

Copy link
Collaborator

@epage epage left a comment

Choose a reason for hiding this comment

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

Be sure to read my comment about extension traits before applying other feedback

/// Err(ErrMode::Backtrack(Error::new(BStr::new(";"), ErrorKind::Verify))),
/// );
/// ```
fn output_stream(self) -> OutputStream<Self, I, O, E>
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think I prefer recognize, rather than output as that does clarify what the stream's range is

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yep, recognize_stream also feels more fitting to me. Will rename it when I polish the PR.

Comment on lines +1009 to +1015
match self.parser.parse_next(input.clone()) {
Ok((remaining, _)) => {
let offset = input.offset_to(&remaining);
let (remaining, slice) = input.next_slice(offset);
Ok((remaining, input.update_slice(slice)))
}
Err(e) => Err(e),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should the streams be marked complete?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe I'm missing something, but how would I mark a stream as complete?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@@ -212,29 +216,29 @@ pub trait Parser<I, O, E> {

/// Produce the consumed input with the output
///
/// Functions similarly to [recognize][Parser::recognize] except it
/// returns the parser output as well.
/// Functions similarly to [`recognize`][Parser::recognize] except it returns the parser output
Copy link
Collaborator

Choose a reason for hiding this comment

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

Unrelated changes will need to be reverted

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can do that, but I thought it would make sense to add the missing backticks around recognize as part of this PR to align it with the docs of the new methods since they are related.

Copy link
Collaborator

Choose a reason for hiding this comment

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

If so, that should be a separate commit

/// Err(ErrMode::Backtrack(Error::new(BStr::new(";"), ErrorKind::Verify))),
/// );
/// ```
fn output_stream(self) -> OutputStream<Self, I, O, E>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could length_value be updated to use this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll have a look.

/// consumed_parser.parse_next(BStr::new("abcd")),
/// );
/// ```
fn with_output_stream(self) -> WithOutputStream<Self, I, O, E>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Have you considered trying these out on an extension trait in your crate first to explore their usage?

I am considering doing 0.5 in the next couple months, so we do have room to change things soon if we aren't thrilled with it. I'm just exploring (and reminding myself) what the options are for these

Copy link
Contributor Author

@martinohmann martinohmann Apr 29, 2023

Choose a reason for hiding this comment

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

I didn't consider that yet, no. But it's a great idea and I'll do this to see if the additional methods are really that useful as I imagine. Will report back once I did that.

I already played around with output_stream in my hcl-edit parser by pointing it against my local winnow fork and it actually helped to simplify one of my use cases quite a bit. Didn't check how (if) with_output_stream would help simplifying the parsers that receive a state parameter yet, but I did a small PoC in a bigger unit test that I didn't bundle with the PR yet to verify that state updates within a map operation actually work the way I expect.

@martinohmann
Copy link
Contributor Author

@epage I think the new &mut Input implementation could change things here. I'm going to revisit this on top of the v0.5 release and see what we get.

@coveralls
Copy link

coveralls commented Oct 7, 2024

Pull Request Test Coverage Report for Build 4722337009

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

Details

  • 0 of 24 (0.0%) changed or added relevant lines in 2 files are covered.
  • 1 unchanged line in 1 file lost coverage.
  • Overall coverage decreased (-0.5%) to 52.597%

Changes Missing Coverage Covered Lines Changed/Added Lines %
src/parser.rs 0 2 0.0%
src/combinator/mod.rs 0 22 0.0%
Files with Coverage Reduction New Missed Lines %
src/parser.rs 1 65.45%
Totals Coverage Status
Change from base Build 4533295401: -0.5%
Covered Lines: 1296
Relevant Lines: 2464

💛 - Coveralls

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.

3 participants