#parser-combinator #error-reporting #zero-dependency #input #pattern #flexible #next-gen

no-std shrimple-parser

Zero-dependency next-gen parsing combinator library with flexible error reporting

13 releases

new 0.0.13 Mar 19, 2025
0.0.12 Mar 15, 2025
0.0.5 Feb 12, 2025
0.0.4 Sep 24, 2024
0.0.3 May 16, 2024

#84 in Parser tooling

Download history 11/week @ 2024-12-06 1/week @ 2024-12-13 88/week @ 2025-02-07 97/week @ 2025-02-14 8/week @ 2025-02-21 9/week @ 2025-02-28 102/week @ 2025-03-07 758/week @ 2025-03-14

877 downloads per month
Used in 2 crates

MIT license

94KB
2K SLoC

Zero-dependency library with no-std support for writing parsers in a concise functional style & with rich error-reporting.

Every parser is a function that maps an Input. Parsers can match on Patterns.

The basic form of the function is

use shrimple_parser::{Input, ParsingResult};

fn parse_foo<In: Input>(input: In) -> ParsingResult<In, Foo, FooParseError> { ... }

If the parser is infallible, i.e. never returns an unrecoverable error, it's customary to make it generic over the reason type, to make combining it easier.

fn parse_foo<In: Input, Reason>(input: In) -> ParsingResult<In, Foo, Reason> { ... }

Kinds of errors are distinguished via a user-defined Reason type, which signals what did a parser expect. A ParsingError can also have no reason, which will mean that the error is recoverable.

Some built-in parsers can have core::convert::Infallible as their error reason, which means that any error the parser may ever return is recoverable.

The distinction between recoverable & fatal errors is important for parsers that need to try multiple options.

Error reporting with precise location in the source is facilitated by constructing a FullParsingError with methods such as Parser::with_full_error, ParsingError::with_src_loc

Dependencies