@formscript/parser

Tokens → abstract syntax tree, per §4 of the specification.

Usage

import { tokenize } from '@formscript/lexer';
import { parse } from '@formscript/parser';

const { tokens } = tokenize(source);
const { document, diagnostics } = parse(tokens, { file: 'application.forms' });

parse takes tokens, not source text. The lexer owns the token contract; the parser owns the grammar. Keeping them apart means the parser never has to re-derive a lexical rule, and it makes the grammar table of §4 mechanically checkable by @formscript/spec-lint.

How it parses

Recursive descent, with precedence climbing for the binary operators. The soft-keyword resolution table of §4.14 decides whether an identifier is an attribute name, a block kind, a match arm key, or a plain reference.

parse never throws either. Every problem is an E-SYN-* diagnostic with a line:column.

Notes

• inapplicable is a hard keyword and a literal kind (§3.6).
• not is a hard keyword and a word form of ! (§6.2).
• match is a hard keyword, so it is parsed in the keyword branch rather than the identifier branch.

Public API

3 exported symbols.