Question about including error recovery when adding marser library

[ArneCode]

Hi! I am the author of marser, a parser-combinator library for writing PEG-style grammars in Rust with a focus on useful errors, error recovery and good performance.

Before opening a PR I wanted to ask whether it makes sense to include error handling in the example. I have seen that you discussed including comparisons of error quality before in issue #4. But including error recovery and additional rules for providing extra information will lead to slower speeds of the example.
I have created two versions of a json parser in a fork of this library, one with error rules and one without. Which would fit better in this benchmark?
You can find an example of what json parsing with error rules looks like here.

Additionally, marser has optional support for rendering diagnostics using annotate-snippets. That feature increases compile times and binary size somewhat, so I currently do not enable it in the benchmark examples. Would it make sense to add it to the benchmark examples?

Also this is a very new library (0.1.2), I have just released it two days ago. Is it still ok to add it to this benchmark?

Thank you in advance for your time!

[epage]

Before opening a PR I wanted to ask whether it makes sense to include error handling in the example. I

Our general rule when adding parsers is that we want to use what is considered idiomatic within the library. These should be pulled from the examples of the library.

This is to avoid people over-optimizing for a "benchmark" and to make it easier to update for us as we don't have to worry about how to migrate to every new breaking change for every library.

That said, we generally require some level of notoriety to avoid being bloated with every parser. This usually comes about by either enough use or something unique about the design.

[ArneCode]

Thank you for your answer!

Our general rule when adding parsers is that we want to use what is considered idiomatic within the library

That makes sense! The library is intended to be used with error handling, so I think the error handling example is more fitting, even though it is a bit slower.

That said, we generally require some level of notoriety to avoid being bloated with every parser. This usually comes about by either enough use or something unique about the design.

Because it is new, the library doesn't have much usage yet but it has some points that might be interesting for the test suite:

• Inline PEG Grammar with native rust expressions - While peg also has Inline PEG Grammars, they are written in a DSL instead of just rust code.
• Defining parser using capture! / bind! syntax: This allows users to only think about the results of main parsers, without having to think about the return values of all combinators. For example this is a definition for a json array:

// defining an array
// capture allows you to "match" an input to a grammar
// while storing results in "buckets". These results can then be
// used to construct the output
// capture!(grammar_with_binds => result)
// the code below corresponds to '[' (element (',' element)*)? ']' plus whitespace handling
let array = capture!((
        '[',
        whitespace.clone(),
        optional((
            // this binds the result of the element parser in the
            // elements bucket. The * before elements means that the bucket is a vector
            // ?{name} for Optional and just {name} for just the value
            bind!(element.clone(), *elements), 
            many((
                ',', 
                whitespace.clone(),
                bind!(element.clone(), *elements) // * can be bound to multiple times
            )),
        )),
        whitespace.clone(),
        ']',
        whitespace.clone()
    )
    // we can then use the result from the matching to construct the return value of the parser
    =>  JsonValue::Array(elements) 
);

(This example also requires that whitespace and element are already defined. I have a full json parser example here)

We only need to think about the return values in the bind! statements and in the return value after =>.

• A couple of features other libraries also have but that I think are still worth comparing: zero copy parsing, supporting different input types, support for error recovery and good diagnostics, allowing for packrat-style caching etc.

An example of error diagnostics generated by marser, rendered with annotate-snippets:

If its ok, I would start doing a pull request.

[epage]

Maybe this is my own biases but I'm not seeing this as novel enough. It is another parser combinator library with error recovery. The main differentiator is explicitly requesting values rather than explicitly ignoring values. Creating bindings to then populate a struct isn't too dissimilar to nom-derive or winnow::combinator::seq!

[ArneCode]

Thank you for your response!

The main differentiator is explicitly requesting values rather than explicitly ignoring values.

yes, that is true but I believe that this makes a difference.
The aim for marser is that you can just write PEG grammars for the parsing logic using marser notation.

For all parser combinator libaries I have seen you have two options for handling output values:

• igore values directly (with preceeded / then_ignore etc) or
• ignore the values later for example during tuple destructuring.

If you want to write just PEG grammars for the parsing logic you cannot use the first option because you will need to add extra statements to the logic like preceeded / then_ignore etc.
But I believe the second option also leads to hard to read tuple destructuring code. If you then want to modify the grammar somehow, you need to modify this logic which I believe is difficult because it is difficult to reason about. When parsers are written in the start I believe there will be a lot of iteration which is made harder by relatively complex tuple code.

A very subjective opinion so you may disagree: I believe this comes from a mismatch between what programmers care about when writing parsers vs what code they need to write.
When writing parsers, programmers care about the values they want to use but in parser combinator libraries they need to specify what values they dont want to use.

Why I think writing parsers using just PEG expressions is useful:

• Many poeple already know PEG or something like EBNF, so I believe they are able to read PEG like code easily. If you want to know exactly what the grammar is, you can just look at the code and the grammar is there.
• I also believe that this makes parsing code like this easier to write if you already know PEG. You just need to look up the function names for the operators you already know.

Creating bindings to then populate a struct isn't too dissimilar to [nom-derive](https://crates.io/crates/nom-derive) or [winnow::combinator::seq!](https://docs.rs/winnow/latest/winnow/combinator/macro.seq.html)

As far as I can see nom-derive does not have functionality for expecting a certain input like "[" or handling repetition, so I think it cannot be used in similar ways as marser capture/bind , but it is possible that I have missed something.

winnow seq! is interesting because I think it is going in a similar direction as marser. But there are some differences. For example this is what I think the array code from above would look like if written using seq!:

seq!(
    _: '[',
    _: whitespace,
    opt(seq!(
        element,
        repeat(0.., seq!(
            _: ',',
            _: whitespace,
            element,
        )),
    )),
    _: whitespace,
    _: ']',
)
.map(|(elements,): (Option<(JsonValue, Vec<(JsonValue,)>)>,)| {
    let elements = match elements {
        None => vec![],
        Some((first, rest)) => {
            let mut v = vec![first];
            v.extend(rest.into_iter().map(|(e,)| e));
            v
        }
    };
    JsonValue::Array(elements)
})

But you still need to explicitly ignore everything you are not using. You also still need to have mapping logic to destructure the tuples.This may also still require changing this logic when changing the grammar, making iterating on the grammar difficult, so I still believe it has the same disadvantages as other parser combinator approaches.

I believe this difference between requesting values vs ignoring values makes it possible to write parsers in a different way to other parser combinator libraries, which I believe makes it distinct.

Thank you in advance for taking the time to read through this!

[epage]

If you want to write just PEG grammars for the parsing logic you cannot use the first option because you will need to add extra statements to the logic like preceeded / then_ignore etc.

Conversely, aren't you adding extra statements to the logic to capture values with bind!?