Repository navigation
Algorithms and Limitations
ISPA uses loadable algorithm plugins. LL is the production parser target and the recommended choice for real grammars. It is actively growing, and its feature set and diagnostics continue to improve. LR (LR0) and LALR (LR1) are less capable for now: they share grammar and AST type generation, but support fewer grammar features and remain experimental. LR(*) has a plugin interface and currently rejects builds.
| Capability | LL | LR / LALR |
|---|---|---|
| Ordinary grammar recognition and captures | Yes | Yes, experimental |
| Left recursion | Not a general LL feature | Yes |
Advanced rules with ordinary match clauses |
Yes | Yes |
| Embedded Python actions, multiple conditional matches | Yes | Rejected |
| Rule parameters, shared counters, dynamic patterns | LL path | Rejected |
| External parser calls | Yes, with lazy lexing | Rejected |
| Fail blocks and recovery | Yes | Not generated |
| Error diagnostics | Local/context errors | Missing ACTION diagnostics in deterministic runtime |
LR automatic conflicts can use lookahead up to --lr-conflict-lookahead (default 3), then deferred runtime branching. The generalized conflict runtime has different diagnostics from the deterministic runtime. AST rule source spans are not populated in LR, although token captures keep lexer positions.
See the repository's docs/LR_STATUS.md for detailed implementation status and lib/algorithm/README.md for the plugin/cache design. If your grammar uses semantic actions, recovery, or imported parsers, use -a LL.