tree-sitter-swi-prolog

SWI-Prolog grammar for tree-sitter.

It parses the Prolog that real SWI-Prolog projects are written in, not only ISO core:

• the default SWI-Prolog operator table, including : module qualification, => single-sided unification, =@=, >:<, :<, as, $, and declaration prefixes such as dynamic, discontiguous, meta_predicate, multifile and table
• operators from common libraries: library(clpfd) (#=, in, .., ...), library(chr) (<=>, ==>, \), library(semweb/rdf_db) (^^), library(wasm) (#Value, Expr[Index]) and the rdf_meta, persistent, record and html_meta declarations
• dicts (_{name: "x"}, Tag{...}) and functional notation on dicts (D.key, D.put(k, V))
• strings, back-quoted strings, 0'c character codes, radix integers (16'FF), digit groups (1 000 000), rationals (1r3) and special floats (1.0Inf)
• Unicode atoms and variables, multi-line quoted text, % and /* */ comments, and a leading #! line
• the clause terminator: a . followed by layout (any Unicode white space character), a % comment or the end of the input ends the clause, and a . followed by any other character does not, as in a.b or X =.. L

Clauses are structured for tools: every top-level term is a clause (with head, neck and body fields), a directive or a query.

max(X, Y, X) :- X >= Y, !.

(clause
  head: (compound_term functor: (atom) arguments: (arguments (variable) (variable) (variable)))
  neck: (operator)
  body: (binary_operation left: (binary_operation ...) operator: (operator) right: (atom))
  (end))

Coverage

CI parses SWI-Prolog's own boot/ and library/ sources and fails if fewer than 99.5% of top-level terms parse without errors. On SWI-Prolog's current boot/ and library/ 99.88% of terms parse cleanly, and on the full SWI-Prolog 10.0.2 library with packages (413 files, about 240,000 lines) 99.91%; the rest use prefix operators their files declare themselves.

Limits

A tree-sitter grammar has a fixed operator table, so operators declared at load time with op/3 are not known while parsing:

• an unknown infix operator between two operands, symbolic or alphanumeric (for example X ===> Y or X cis Y), is read as an infix operator at priority 700, so the clause still parses, with the grouping that priority gives
• unknown prefix and postfix operators produce an ERROR node for that term only; the parser recovers at the next clause
• the parser does not lower operator priorities the way SWI-Prolog does in some argument positions, so foo(:- a) or foo(a|b) are errors

A negative number literal is parsed as the prefix operator - applied to the number.

Queries

• queries/highlights.scm: syntax highlighting
• queries/tags.scm: predicate definitions (clause heads, including module-qualified heads and single-sided-unification heads with guards), module declarations, and calls. @name is the predicate name without arity; count the head's arguments for the arity, and add two for DCG rules (neck -->)
• queries/locals.scm: variables are local to their clause, directive or query

Usage

Node, Rust, Python, Go, Swift and C bindings are generated by tree-sitter init. For the browser or other WebAssembly hosts, build the parser with:

npx tree-sitter build --wasm

and load tree-sitter-swi_prolog.wasm with web-tree-sitter.

Development

npm install
npx tree-sitter generate
npx tree-sitter test
npx tree-sitter build --wasm
npm run test:unit
node scripts/check-corpus.mjs path/to/prolog/sources

The unit tests in test/unit/ cover all of the project's own code: grammar.js and grammar/ (every node type, field and child type in src/node-types.json is produced by a sample), the queries (every pattern matches), src/scanner.c (with a C unit test) and the scripts. npm run coverage runs them and fails below 100% (it needs gem install bashcov for the shell scripts). npm run mutation runs mutation testing: Stryker on the JavaScript, regenerating the parser for each grammar mutant, and test/mutation/mutants.mjs on src/scanner.c and the shell scripts.

grammar/operators.js lists the operator tables. To support another library's operators, add them to the matching table with their SWI-Prolog priority and type.

Releasing

Releases are made from changesets.

1. A pull request with a user-visible change adds a changeset: run npx changeset, pick the bump and describe the change for users. CI fails a pull request without a changeset; for a change users don't see, add an empty one with npx changeset --empty.
2. When it is merged, the Release workflow opens (or updates) a Version packages pull request that applies all pending changesets: it bumps the version in every manifest and writes their text into CHANGELOG.md.
3. Merging that pull request releases the new version: the vX.Y.Z tag and GitHub release (with the changelog section as notes and the Wasm parser attached), npm, crates.io and PyPI.

The release step publishes only what is missing for the current version, so if a registry fails, run the Release workflow again from the Actions tab. Don't create tags or releases by hand.

License

MIT