timsueberkrueb/yalr

Yet Another LR parser generator

YALR

YALR (Yet Another LR parser generator) is a Rust library for generating LALR(1) parsers.

IMPORTANT: YALR is early work in progress and currently in an early prototypical state. Here be dragons.

Features

• Straightforward syntax - no custom grammar files, only Rust code and macros
• Tooling included - Parser introspection tooling included (LALR parse table, LALR state diagram)
• Lexer-independent - Works with any lexer that implements the Lexer trait

Build

Rust >= 1.31.0 is required to build YALR.

Usage

Examples can be found in the examples directory.

License

YALR is licensed under either of the following licenses, at your option:

• Apache License Version 2.0
• MIT License

yalr's Issues

Docs

Create documentation with code examples. The code examples should get tested.

• yalr
  • Document logos_support
• yalr_cli
  • Document all public features
    • table (and options)
    • graph (and options)
• yalr_codegen
  • Document the fact that this is not stable and not fit for public consumption, yet
• yalr_core
  • Document all public types
    • TODO: add checklist
• yalr_proc_macro
  • Document the syntax rules for rule
  • Document terminal_type
  • Document assoc
  • Document lalr

Create beginners guide or tutorial

Support parser modularization

Benchmarks

Generate JSON tests using build.rs

Support methods taking self

Improve API and structure

We should get rid of unnecessary attributes and use standard language features over macros whenever possible.

This is a rough sketch of what it could look like:

impl LALR for Parser {
    type T = Terminal;
    type N = Nonterminal;
    const START: Self::N = Nonterminal::Start;
    const END: Self::T = Terminal::End;
    type Input = str;
    type Output = f32;
}

#[lalr]
#[assoc(...)]
impl Parser { /* Rule functions ... */ }

where LALR is a trait defined as:

trait LALR {
    type T;
    type N;
    const START: Self::N;
    const END: Self::T;
    type Input;
    type Output;
}

Tests

Tests are needed, especially for yalr_core.

Unit tests

• yalr_core
  • add checklist here

Integration tests

• All examples should be run as integration tests.

Doc tests

• Code in docs should be tested.

Support propagating results

When a rule function returns a Result, it should be possible to opt-in to a behavior which stops parsing and propagate the Err value to the caller of the parse function.

Parse non-text formats (example)

Optional no_std support

• Fixed/max stack size

Warn if terminal in assoc decl is not being used

Add trace feature for lexers

Allowing the user to trace lexer results would improve the debugging experience.
This should be implemented similar to the parser trace feature: print the current token after each advance as well as the first token after initializing the lexer.