https://docs.rs/nom/5.0.1/nom/macro.tag_bits.html documentation says that tag_bits signature is tag_bits!(type, count, pattern). The first parameter, type, was removed in the commit 0313c1d63fe5fd074989c958073f2340385a1d43, but documentation was not updated.

take_bits! documentation has a similar issue.

https://github.com/Marwes/combine/blob/v4.0.0-beta.1/src/parser/mod.rs#L70

...needs to be at least one implementation of two parse_streams or one parse_lazy? I'm not sure what the third option should be, or if there are only two options.

Is the pyparsing class diagram still accurate? The last version it was generated for is 1.5.2, but it looks about right.

A few restrictions are supported for “holes” already.
A search for alphanumeric characters and punctuation can be specified by a syntax which is slightly different from other filter possibilities.

I imagine that advanced filters could be specified directly after the match identifier.

• Character class
• Regular expression
• Predefi

Macro tags are flags that serve as meta information #4. Turns out it may be a good thing to allow macro tags to have arguments:

macro ·name('MyMacro') { /* match */ } >> { /* expansion */ }

Blocks #15

It would be nice to add the bits of code from chapter 33 of "Programming in Scala" as tests to be sure we don't break compatibility (too much) with the book.

Even though it is stated that LINQ query syntax should be avoided due to performance reduction - Is there a chance, that the documentation could be enhanced by laying out the examples in both syntax styles?

As a learner who tries to get get his head around parsing things, I find myself to be much more comfortable using the LINQ query syntax, as it is much easier to read and understand. That is

It would be nice to have autogenerated documentation link available online and linked from the README. Currently there is https://docs.mirage.io/angstrom/Angstrom/index.html autogenerated by Mirage OS team.

See also discussion on building a central documentation site: https://discuss.ocaml.org/t/central-opam-documentation-site/3886/33

The 1.69 version of the documentation had the code for the expressions for the operators on this page:
https://www.boost.org/doc/libs/1_69_0/libs/spirit/doc/x3/html/spirit_x3/quick_reference/operator.html

The code snippets in the first column are replaced by useless text since 1.70:
https://www.boost.org/doc/libs/1_70_0/libs/spirit/doc/x3/html/spirit_x3/quick_reference/operator.html
https://

From the tutorial:

See how composition works. We compose a parser some(...) of type Parser(Token, Token) with the function tokval and we get a value of type Parser again, but this time it is Parser(Token, str). Let's put it this way: the set of parsers is closed under the application of >> to a parser and a function of

Most of the gll-combinators test suite is highly applicable to parseback, and the syntax is very very close. It should be relatively easy to port over most of the tests. As an initial spike, any test which is failing should just be marked as pendingUntilFixed.

The gll-combinators test suite is here.

Hi,
I don't know if its possible but maybe this can be somehow handled better:

If I have a grammar rule like so:

cppcmb_def(expr) = pc::pass
                   | (expr & match<Token::PLUS> & primary) [BinaryExpr::make]
                   | (expr & match<Token::MINUS> & primary) [BinaryExpr::make]
                   | primary
                   %= pc::as_memo_d;

And the met