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

Help people discover how to do take_while, et al, with parsers instead of predicates #1416

Open
epage opened this issue Sep 28, 2021 · 2 comments
Milestone

Comments

@epage
Copy link
Contributor

epage commented Sep 28, 2021

Prerequisites

Here are a few things you should provide to help me understand the issue:

  • Rust version : 1.55.0
  • nom version : 7.0.0
  • nom compilation features used: default

Test case

It was unclear how to do take_while with a parser, rather than a predicate, so I wrote my own take_many, used like

        take_many0(alt((
            // CAUTION: If adding an ignorable literal, if it doesn't start with `is_xid_continue`,
            // - Update `is_ignore_char` to make sure `sep1` doesn't eat it all up
            // - Make sure you always consume it
            terminated(uuid_literal, sep1),
            terminated(hash_literal, sep1),
            terminated(hex_literal, sep1),
            terminated(dec_literal, sep1),
            terminated(ordinal_literal, sep1),
            terminated(base64_literal, sep1),
            terminated(email_literal, sep1),
            terminated(url_literal, sep1),
            terminated(c_escape, sep1),
            terminated(printf, sep1),
            sep1,
        )))(input)

Turns out, there are built-in ways of doing this with recognize and many0_count.

@epage
Copy link
Contributor Author

epage commented Sep 28, 2021

One thought on this:

  • Have take_while* says "if you need to use a predicate, see recognize and add an example to recognize for this
  • Have many* link to ``many0_count` for a non-allocating consuming (since the name doesn't stand out for that intention)
  • Have many*_count link to recognize as well.

@epage
Copy link
Contributor Author

epage commented Jan 14, 2022

Lack of #1393 makes this a bit annoying to deal with.

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

2 participants