eyelang 1.4.1 → 1.5.0

package/README.md

@@ -5,10 +5,10 @@
 
 eyelang is a small rule engine for Prolog-style Horn clauses over ordinary terms, lists, arithmetic, strings, and finite search. The command-line executable is `eyelang`.
 
-Programs write relations directly, for example `ancestor(pat, emma)` or `status(case1, accepted)`. eyelang output is ordinary eyelang syntax: by default, it prints answer facts only. Pass `--proof` (or `-p`) when you also want each answer followed by a `why/2` explanation fact that records the proof. When no `--query` is supplied, the CLI materializes distinct new binary derivations of the form `p(S, O)`, suppresses repeated source facts, and prints each derived answer. Programs may add `materialize(Name, Arity).` declarations to focus default output on selected predicates.
+Programs write relations directly, for example `ancestor(pat, emma)` or `status(case1, accepted)`. eyelang output is ordinary eyelang syntax: by default, the CLI materializes selected answer facts and prints those facts only. Pass `--proof` (or `-p`) when you also want each answer followed by a `why/2` explanation fact that records the proof. Programs may add `materialize(Name, Arity).` declarations to focus output on selected predicates.
 
 
-Try it in the [browser playground](https://eyereasoner.github.io/eyelang/playground). The playground includes run options equivalent to CLI `--query`, `--stats`, and `--proof`.
+Try it in the [browser playground](https://eyereasoner.github.io/eyelang/playground). The playground includes run options equivalent to CLI `--stats` and `--proof`.
 
 For the normative language definition, including lexical syntax, terms, clauses, goals, built-ins, `memoize/2`, `materialize/2`, and conformance boundaries, read the [eyelang specification](SPEC.md).
 
@@ -34,12 +34,11 @@ Install dependencies, if any, and run the command-line executable:
 npm install
 ```
 
-There is no build step for the CLI. Run examples, explicit queries, multiple inputs, stdin, or a URL:
+There is no build step for the CLI. Run examples, multiple inputs, stdin, or a URL:
 
 ```sh
 bin/eyelang --version
 bin/eyelang examples/ancestor.pl
-bin/eyelang --query 'ancestor(pat, X)' examples/ancestor.pl
 bin/eyelang facts.pl rules.pl
 printf 'works(stdin, true) :- eq(ok, ok).\n' | bin/eyelang -
 bin/eyelang https://raw.githubusercontent.com/eyereasoner/eyelang/refs/heads/main/examples/ancestor.pl
@@ -69,20 +68,14 @@ Run a program and let eyelang print derived binary facts:
 bin/eyelang examples/ancestor.pl
 ```
 
-Run an explicit query:
-
-```sh
-bin/eyelang --query 'ancestor(pat, X)' examples/ancestor.pl
-```
-
 Enable proof explanations when you want machine-readable provenance:
 
 ```sh
-bin/eyelang --proof --query 'ancestor(pat, X)' examples/ancestor.pl
+bin/eyelang --proof examples/ancestor.pl
 bin/eyelang -p examples/ancestor.pl
 ```
 
-eyelang-readable explanations are opt-in proof output. Each `why/2` fact contains a nested abstract proof term, and a blank line separates consecutive explanations. Using eyelang syntax for explanations keeps them in the same language as the answers themselves: they are readable by humans, parseable by eyelang, easy to test, and can be queried, transformed, or explained further like any other eyelang data. For example:
+eyelang-readable explanations are opt-in proof output. Each `why/2` fact contains a nested abstract proof term, and a blank line separates consecutive explanations. Using eyelang syntax for explanations keeps them in the same language as the answers themselves: they are readable by humans, parseable by eyelang, easy to test, and can be transformed or explained further like any other eyelang data. For example:
 
 ```prolog
 type(socrates, mortal).
@@ -103,7 +96,7 @@ why(
 
 ```
 
-The explanation output can itself be read as eyelang input and queried, for example `why(type(socrates, mortal), Proof)`. `--proof` adds only these explanation facts; it does not change the answers found by the solver.
+The explanation output can itself be read as eyelang input; for example, another program can materialize `why/2` facts such as `why(type(socrates, mortal), Proof)`. `--proof` adds only these explanation facts; it does not change the answers found by the solver.
 
 ### Explanation cookbook
 
@@ -112,7 +105,7 @@ eyelang answers can carry their own provenance when proof output is enabled.
 Explain one derived fact:
 
 ```sh
-bin/eyelang --proof --query 'type(socrates, mortal)' examples/socrates.pl
+bin/eyelang --proof examples/socrates.pl
 ```
 
 The output contains the answer and a `why/2` fact. The proof term shows the source rule that produced the answer and the source fact used below it. Source references use `rule("file.pl", clause(N))` and `fact("file.pl", clause(N))`, where `N` is the 1-based clause number in that file.
@@ -130,7 +123,7 @@ status(Case, accepted) :-
 ```
 
 ```sh
-bin/eyelang --query 'status(Case, accepted)' policy.pl
+bin/eyelang --proof policy.pl
 ```
 
 The explanation contains the instantiated answer and the variables that made the rule succeed:
@@ -153,12 +146,10 @@ Use the `uses([...])` list to follow the proof tree. In the policy example it co
 Reuse explanations as data:
 
 ```sh
-bin/eyelang --proof --query 'type(socrates, mortal)' examples/socrates.pl > socrates.why.pl
-bin/eyelang --query 'why(type(socrates, mortal), Proof)' socrates.why.pl
+bin/eyelang --proof examples/socrates.pl > socrates.why.pl
 ```
 
-When a query has no answers, eyelang prints no answers and no explanations. That makes missing proofs explicit without inventing a reason.
-
+The resulting file is ordinary eyelang syntax containing both answers and `why/2` proof facts.
 
 Compose multiple files, stdin, and URLs:
 
@@ -168,12 +159,6 @@ printf 'works(stdin, true) :- eq(ok, ok).\n' | bin/eyelang -
 bin/eyelang https://example.test/program.pl
 ```
 
-`--query GOAL` parses a single goal. Parenthesized conjunctions are accepted:
-
-```sh
-bin/eyelang --query '(ancestor(pat, X), ancestor(X, emma))' examples/ancestor.pl
-```
-
 ## Default output
 
 eyelang programs write relation predicates directly:
@@ -186,7 +171,7 @@ ancestor(X, Y) :- parent(X, Y).
 ancestor(X, Z) :- parent(X, Y), ancestor(Y, Z).
 ```
 
-Without `--query`, eyelang asks for new ground binary consequences of the shape `p(S, O)`, suppresses duplicates, excludes source facts, sorts the result, and prints Prolog facts:
+By default, eyelang asks for new ground consequences of selected output predicates, suppresses duplicates, excludes source facts, sorts the result, and prints Prolog facts:
 
 ```prolog
 ancestor(jan, emma).
@@ -194,11 +179,11 @@ ancestor(pat, emma).
 ancestor(pat, jan).
 ```
 
-This default is intentionally output-oriented. It is not a complete bottom-up saturation engine. Built-ins and proof search remain goal-directed; use `--query` when you want a specific relation, arity, or non-binary answer.
+This default is intentionally output-oriented. It is not a complete bottom-up saturation engine. Built-ins and proof search remain goal-directed; use `materialize/2` declarations and small output predicates when you want a specific relation, arity, or non-binary answer.
 
 ### Focusing default output
 
-Large examples often have internal helper predicates. Add `materialize(Name, Arity).` declarations to restrict no-query output to selected predicates:
+Large examples often have internal helper predicates. Add `materialize(Name, Arity).` declarations to restrict default output to selected predicates:
 
 ```prolog
 materialize(answer, 2).
@@ -214,7 +199,7 @@ The default output is then:
 answer(case1, accepted).
 ```
 
-`materialize/2` is a declaration, not a logical rule to prove. It does not affect explicit `--query` answers.
+`materialize/2` is a declaration, not a logical rule to prove. It affects which predicates the CLI prints, not the meaning of the rules themselves.
 
 ## Writing programs
 
@@ -250,20 +235,14 @@ materialize(reason, 2).
 
 Predicate names and atom constants use the same lexical form. Namespace-like names should be plain names such as `type`, `person_name`, or `odrl_permission`; colon names are not part of the language.
 
-### Queries remain general
+### Embedding remains general
 
-The default output focuses on materialized binary facts, but the query engine supports arbitrary goals and arities:
-
-```sh
-bin/eyelang --query 'append(A, B, [a, b])' examples/list-collection.pl
-bin/eyelang --query 'ackermann(4, 2, A)' examples/ackermann.pl
-bin/eyelang --query 'once(solution(classic, S))' examples/sudoku.pl
-```
+The CLI is output-oriented and uses `materialize/2` to decide what to print. Embedders can still use the JavaScript API and `Solver` directly for arbitrary goals and arities.
 
 Add `--stats` when you want lightweight solver counters on stderr without changing stdout:
 
 ```sh
-bin/eyelang --stats --query 'once(solution(classic, S))' examples/sudoku.pl
+bin/eyelang --stats examples/sudoku.pl
 ```
 
 The playground has matching `--stats` and `--proof` checkboxes, so browser runs can show the same counters or explanations like the CLI.
@@ -504,7 +483,7 @@ npm run test:regression
 npm run test:examples
 ```
 
-The conformance suite lives in [`conformance/`](conformance/) and is split into `core` and `extension` profiles matching `SPEC.md`. Each case is a small program with optional query text and an exact expected stdout file, so other implementations can reuse the same cases. The regression suite lives in [`test/run-regression.js`](test/run-regression.js) and covers CLI regressions, the public JavaScript API, and white-box invariants for parser, unification, and indexing behavior.
+The conformance suite lives in [`conformance/`](conformance/) and is split into `core` and `extension` profiles matching `SPEC.md`. Each case is a small program with an exact expected stdout file, and some internal conformance cases also include a goal file for testing the embeddable solver, so other implementations can reuse the same cases. The regression suite lives in [`test/run-regression.js`](test/run-regression.js) and covers CLI regressions, the public JavaScript API, and white-box invariants for parser, unification, and indexing behavior.
 
 ## Development and release
 
@@ -521,7 +500,7 @@ node bin/eyelang --help
 Useful profiling smoke test:
 
 ```sh
-bin/eyelang --stats --query 'once(solution(classic, S))' examples/sudoku.pl > /dev/null
+bin/eyelang --stats examples/sudoku.pl > /dev/null
 ```
 
 For a release:
@@ -530,7 +509,7 @@ For a release:
 2. update `README.md` and `SPEC.md`;
 3. regenerate golden outputs if behavior changed;
 4. run `npm test`;
-5. publish the repository with `playground.html` and `playground-worker.mjs` if publishing the playground. The playground includes controls equivalent to CLI `--query GOAL`, `--stats`, and `--proof`.
+5. publish the repository with `playground.html` and `playground-worker.mjs` if publishing the playground. The playground includes controls equivalent to CLI `--stats` and `--proof`.
 
 ## Performance notes
 
@@ -550,8 +529,8 @@ Ground facts use a fast path that avoids freshening and copying a rule body. Rec
 memoize(path, 2).
 ```
 
-For large programs, keep helper predicates selective, bind arguments early, and declare focused output predicates with `materialize/2` when default output would otherwise ask broad helper queries.
+For large programs, keep helper predicates selective, bind arguments early, and declare focused output predicates with `materialize/2` when default output would otherwise solve broad helper goals.
 
 ## Implementation limits
 
-eyelang is intentionally smaller than ISO Prolog. It has no operators, cut, modules, dynamic database updates, DCGs, or complete ISO library. Negation is negation-as-failure through `not/1`. Search is goal-directed and expected to be finite for the supplied program and query. Output explanations are non-normative proof printouts and do not change answer semantics.
+eyelang is intentionally smaller than ISO Prolog. It has no operators, cut, modules, dynamic database updates, DCGs, or complete ISO library. Negation is negation-as-failure through `not/1`. Search is goal-directed and expected to be finite for the selected output goals. Output explanations are non-normative proof printouts and do not change answer semantics.

package/SPEC.md

@@ -87,7 +87,7 @@ A **goal** is an atomic formula, a built-in call, or a comma conjunction.
 
 A **source fact** is a fact written directly in the input program. A **new derivation** is a ground consequence found through at least one rule and not merely repeated from the source facts.
 
-The **Herbrand universe** of a program is the set of all ground eyelang terms constructible from the constants and functors in the program, together with the built-in list constructors `[]` and `./2` where lists are used. The **Herbrand base** is the set of all ground atomic formulas whose predicate symbols occur in the program or query and whose arguments are terms from the Herbrand universe.
+The **Herbrand universe** of a program is the set of all ground eyelang terms constructible from the constants and functors in the program, together with the built-in list constructors `[]` and `./2` where lists are used. The **Herbrand base** is the set of all ground atomic formulas whose predicate symbols occur in the program and whose arguments are terms from the Herbrand universe.
 
 ## 2. Design goals
 
@@ -199,7 +199,7 @@ term         ::= variable
 list_items   ::= term ("," term)* ["|" term]
 ```
 
-Here `atom_constant` is a lexical class for symbolic scalar terms, not an atomic formula. Atomic formulas are represented by the grammar alternative `atom_constant "(" ... ")"` when such a compound appears in a clause head, rule body, or query goal.
+Here `atom_constant` is a lexical class for symbolic scalar terms, not an atomic formula. Atomic formulas are represented by the grammar alternative `atom_constant "(" ... ")"` when such a compound appears in a clause head, rule body, or selected goal.
 
 A clause head SHOULD be a compound term. Non-compound heads are parsed but are not useful in the current predicate index.
 
@@ -214,7 +214,7 @@ value(example, nil()).
 
 ### 5.1 Variables
 
-Variables are scoped to a single clause or query. A variable in a rule head and body denotes the same logical variable within that clause.
+Variables are scoped to a single clause or selected goal. A variable in a rule head and body denotes the same logical variable within that clause.
 
 ### 5.2 Atom constants, strings, and numbers
 
@@ -279,7 +279,7 @@ Clauses with the same predicate name and arity define one predicate group. Predi
 
 Goals are solved left-to-right. For a user-defined atomic-formula goal, eyelang selects candidate clauses by predicate name, arity, and available indexes. A candidate clause is freshened, its head is unified with the goal, and then its body is solved.
 
-A conjunction goal succeeds when all conjunct goals succeed in order. A query answer is printed as the resolved query term followed by a period.
+A conjunction goal succeeds when all conjunct goals succeed in order. An answer is printed as the resolved answer term followed by a period.
 
 ### 7.1 Unification
 
@@ -291,7 +291,7 @@ A goal fails when no built-in case or user clause can prove it. eyelang has no e
 
 ### 7.3 Finite search expectation
 
-Programs and queries SHOULD be written so the relevant search space is finite. eyelang includes recursion guards and memoization support, but it is not required to terminate for arbitrary recursive logic programs.
+Programs and selected output goals SHOULD be written so the relevant search space is finite. eyelang includes recursion guards and memoization support, but it is not required to terminate for arbitrary recursive logic programs.
 
 ## 8. Logical reading: Herbrand semantics
 
@@ -317,7 +317,7 @@ Equivalently, the least Herbrand model is obtained by repeatedly applying the im
 
 ### 8.1 Variables and quantification
 
-Variables do not range over external objects, records, pointers, or host-language values. In the logical reading, variables range over Herbrand terms. A rule is implicitly universally quantified over its variables. A query is existential in the usual logic-programming sense: eyelang searches for substitutions of the query variables by Herbrand terms that make the query true with respect to the program.
+Variables do not range over external objects, records, pointers, or host-language values. In the logical reading, variables range over Herbrand terms. A rule is implicitly universally quantified over its variables. A selected goal is existential in the usual logic-programming sense: eyelang searches for substitutions of its variables by Herbrand terms that make the goal true with respect to the program.
 
 ### 8.2 Equality, identity, and unification
 
@@ -329,7 +329,7 @@ Operationally, eyelang uses first-order unification to find substitutions. The i
 
 eyelang's CLI and library evaluator are goal-directed. They try to prove requested goals by resolving them against facts, rules, and built-ins, using clause order, goal order, indexing, memoization, and deterministic built-in execution. This operational strategy is intended to enumerate answers that are true in the least Herbrand model for the pure Horn-clause fragment, but it is not a complete bottom-up model enumerator. Non-terminating recursion or infinite generators can prevent an answer from being found even when the answer belongs to the least Herbrand model.
 
-The no-query CLI output is also a host behavior, not a separate semantics. It asks broad materialization queries, suppresses duplicates, excludes source facts, keeps ground answers, and prints selected consequences. Explicit `--query` gives direct access to the goal-directed solver.
+Default CLI output is also a host behavior, not a separate semantics. It asks broad materialization goals, suppresses duplicates, excludes source facts, keeps ground answers, and prints selected consequences. Embedders can still access the goal-directed solver directly through the implementation API.
 
 ### 8.4 Built-ins and operational extensions
 
@@ -498,7 +498,7 @@ memoize(path, 2).
 materialize(Name, Arity).
 ```
 
-`Name` MUST be an atom constant and `Arity` MUST be a non-negative integer. If a program contains one or more `materialize/2` declarations, no-query CLI output is restricted to those predicate groups. Source facts are still excluded from printed output.
+`Name` MUST be an atom constant and `Arity` MUST be a non-negative integer. If a program contains one or more `materialize/2` declarations, default CLI output is restricted to those predicate groups. Source facts are still excluded from printed output.
 
 Example:
 
@@ -507,7 +507,7 @@ materialize(status, 2).
 materialize(reason, 2).
 ```
 
-`materialize/2` does not affect explicit queries.
+`materialize/2` affects host output selection only; it does not change the logical meaning of the program.
 
 ## 12. eyelang Sockets
 
@@ -515,7 +515,7 @@ A **eyelang Socket** is a declared semantic opening in a eyelang program where f
 
 The term follows the ordinary socket pattern: a socket defines a place where a matching provider can connect. In eyelang, the matching part is knowledge. A socket identifies what shape of knowledge a program expects; a plug identifies which provider supplies it. This separates reasoning logic from knowledge providers and makes composition boundaries visible as eyelang data.
 
-In this specification, sockets are a portable **programming pattern** expressed with ordinary facts. The core solver does not give `socket/2`, `plug/2`, `provides/1`, or `requires/1` special proof-search behavior unless a host explicitly documents such an extension. Because they are ordinary facts, socket declarations remain readable, queryable, explainable, and safe to ignore by hosts that do not validate them.
+In this specification, sockets are a portable **programming pattern** expressed with ordinary facts. The core solver does not give `socket/2`, `plug/2`, `provides/1`, or `requires/1` special proof-search behavior unless a host explicitly documents such an extension. Because they are ordinary facts, socket declarations remain readable, inspectable, explainable, and safe to ignore by hosts that do not validate them.
 
 ### 12.1 Socket vocabulary
 
@@ -566,7 +566,7 @@ ancestor(X, Z) :-
 
 The `ancestor/2` rules do not depend on a particular storage mechanism for `parent/2`. In a small test, the provider may be the same file. In an embedded host, it may be a database adapter, a document extractor, a remote service, or another eyelang module. The socket facts make that boundary explicit without changing the logical meaning of the rules.
 
-When eyelang derives `ancestor(pat, emma)`, the answer explanation can still refer to the source clauses that were actually used, for example facts for `parent/2` and rules for `ancestor/2`. The socket facts add a queryable description of where such knowledge is intended to enter.
+When eyelang derives `ancestor(pat, emma)`, the answer explanation can still refer to the source clauses that were actually used, for example facts for `parent/2` and rules for `ancestor/2`. The socket facts add an inspectable description of where such knowledge is intended to enter.
 
 ### 12.3 Sockets and AI agents
 
@@ -578,13 +578,13 @@ This gives a clear division of labor: AI can help generate, translate, and conne
 
 Normal answer output prints one resolved answer term followed by a period. Strings are double-quoted; atom constants are quoted when needed; lists use list syntax; compound terms use functor notation. Host interfaces MAY provide an option such as `--proof` to add `why/2` explanation facts; this option MUST NOT change the answers found.
 
-Output SHOULD be accepted as eyelang input when it contains only supported term syntax. Explanations are ordinary eyelang facts, so answer output can be read back and queried by eyelang.
+Output SHOULD be accepted as eyelang input when it contains only supported term syntax. Explanations are ordinary eyelang facts, so answer output can be read back and processed by eyelang.
 
-Without `--query`, the host behavior is:
+Default host output behavior is:
 
 1. parse all inputs into one program;
 2. collect source fact lines for duplicate suppression;
-3. if `materialize/2` declarations exist, query those predicate groups; otherwise query all binary predicate groups with at least one rule;
+3. if `materialize/2` declarations exist, solve those predicate groups; otherwise solve all binary predicate groups with at least one rule;
 4. keep only ground answers;
 5. remove answers identical to source facts;
 6. suppress duplicates;
@@ -617,7 +617,7 @@ A conforming standard host also supports:
 
 - `memoize/2` declarations;
 - `materialize/2` declarations;
-- default no-query derived output;
+- default derived output;
 - explanation output;
 - stdin, file, and URL inputs in the CLI.
 
@@ -679,4 +679,4 @@ status(a, open) :- open(a).
 
 URL input uses host networking support when available. Hosts SHOULD treat downloaded programs as untrusted code because they can trigger expensive search.
 
-Programs SHOULD be written with finite search in mind. Broad no-query materialization can be expensive for helper predicates; use explicit `--query` or `materialize/2` declarations when needed.
+Programs SHOULD be written with finite search in mind. Broad default materialization can be expensive for helper predicates; use `materialize/2` declarations and concise output predicates when needed.

package/conformance/README.md

@@ -5,7 +5,6 @@ This directory contains the executable conformance cases for the eyelang languag
 The suite is intentionally file-based so another implementation can run the same programs and compare exact standard output. A case consists of:
 
 - `conformance/cases/<profile>/<name>.pl` — input program;
-- optional `conformance/cases/<profile>/<name>.query` — query text passed to `eyelang --query`;
 - `conformance/expected/<profile>/<name>.out` — exact expected standard output.
 
 The current runner compares standard output, including answer facts and their `why/2` explanation facts. Standard error, performance, and resource limits are outside this suite.
@@ -31,16 +30,16 @@ node test/run-conformance.js core
 node test/run-conformance.js extension
 ```
 
-The runner executes cases through the public CLI path `bin/eyelang`, so the suite checks the same entry point used from the shell.
+The runner executes materialized programs in-process through the public JavaScript API so small conformance cases avoid measuring Node startup overhead.
 
 ## Profiles
 
-`core` covers the portable core language profile from `../SPEC.md`: lexical syntax, facts, definite clauses, first-order terms, lists, conjunction, unification through user predicates, left-to-right goal-directed proof search, and answer printing with explanations.
+`core` covers the portable core language profile from `../SPEC.md`: lexical syntax, facts, definite clauses, first-order terms, lists, conjunction, unification through user predicates, left-to-right goal-directed proof search, and answer printing.
 
-`extension` covers the standard built-in and host behavior exercised by the current reference implementation: arithmetic, comparison, strings, list relations, aggregation, formula-term helpers, `memoize/2`, `materialize/2`, and default no-query derived output.
+`extension` covers the standard built-in and host behavior exercised by the current reference implementation: arithmetic, comparison, strings, list relations, aggregation, formula-term helpers, `memoize/2`, `materialize/2`, and default derived output.
 
 The profile name `extension` is a test-suite grouping name. It does not mean that these cases are outside the eyelang specification; most of them correspond to the standard built-in profile and standard host profile in `../SPEC.md`.
 
 ## Updating expected output
 
-There is no committed auto-accept mode. To update an expected file, run the matching case with `bin/eyelang`, inspect the result, and replace the corresponding file under `conformance/expected/<profile>/` deliberately.
+There is no committed auto-accept mode. To update an expected file, run the matching case with the conformance runner, inspect the result, and replace the corresponding file under `conformance/expected/<profile>/` deliberately.

package/conformance/cases/core/001_fact_output.pl

@@ -0,0 +1,4 @@
+% SPEC 6, 7, 11: facts can be exposed through a materialized derived predicate.
+materialize(parent, 2).
+base_parent(pat, jan).
+parent(X, Y) :- base_parent(X, Y).

package/conformance/cases/core/002_rule_recursion.pl

@@ -1,5 +1,7 @@
 % SPEC 6, 7: definite clauses, conjunction, and recursive proof search.
+materialize(ancestor, 2).
 parent(pat, jan).
 parent(jan, emma).
-ancestor(X, Y) :- parent(X, Y).
-ancestor(X, Z) :- parent(X, Y), ancestor(Y, Z).
+ancestor_any(X, Y) :- parent(X, Y).
+ancestor_any(X, Z) :- parent(X, Y), ancestor_any(Y, Z).
+ancestor(pat, Y) :- ancestor_any(pat, Y).

package/conformance/cases/core/003_terms_and_readback.pl

@@ -1,14 +1,16 @@
 % SPEC 3, 5, 11: scalars, compounds, lists, and read-back printing.
-value(atom, pat).
-value(quoted_atom, 'atom with spaces').
-value(quoted_quote, 'needs''quote').
-value(empty_atom, '').
-value(string, "line\nquote: \"ok\"").
-value(integer, -42).
-value(decimal, 0.25).
-value(scientific, 1.25e-3).
-value(compound, pair(3, nested(atom, [x, y]))).
-value(zero_arity, nil()).
-value(empty_list, []).
-value(proper_list, [a, b, c]).
-value(improper_list, [a, b | tail]).
+materialize(value, 2).
+raw_value(atom, pat).
+raw_value(quoted_atom, 'atom with spaces').
+raw_value(quoted_quote, 'needs''quote').
+raw_value(empty_atom, '').
+raw_value(string, "line\nquote: \"ok\"").
+raw_value(integer, -42).
+raw_value(decimal, 0.25).
+raw_value(scientific, 1.25e-3).
+raw_value(compound, pair(3, nested(atom, [x, y]))).
+raw_value(zero_arity, nil()).
+raw_value(empty_list, []).
+raw_value(proper_list, [a, b, c]).
+raw_value(improper_list, [a, b | tail]).
+value(K, V) :- raw_value(K, V).

package/conformance/cases/core/004_conjunction_and_parentheses.pl

@@ -2,3 +2,4 @@
 p(a).
 q(a).
 ok(X, yes) :- (p(X), q(X)).
+materialize(ok, 2).

package/conformance/cases/core/005_list_deconstruction.pl

@@ -3,3 +3,4 @@ first([X | _Rest], X).
 tail([_Head | Tail], Tail).
 answer(first, X) :- first([a, b, c], X).
 answer(tail, Tail) :- tail([a, b, c], Tail).
+materialize(answer, 2).

package/conformance/cases/core/006_comma_formula_data.pl

@@ -1,3 +1,4 @@
 % SPEC 5.5: comma terms remain data outside goal position.
 record((name(alice, "Alice"), knows(alice, bob))).
 answer(formula, F) :- record(F).
+materialize(answer, 2).

package/conformance/cases/core/007_anonymous_variables.pl

@@ -2,3 +2,4 @@
 pair(a, one).
 pair(b, two).
 answer(fresh, yes) :- pair(a, _), pair(b, _).
+materialize(answer, 2).

package/conformance/cases/core/008_graphic_atoms.pl

@@ -1,4 +1,6 @@
 % SPEC 3.5, 5.2, 11: graphic atom constants are scalar terms.
-value(hash, #).
-value(arrow, =>).
-value(comparison, =<).
+materialize(value, 2).
+raw_value(hash, #).
+raw_value(arrow, =>).
+raw_value(comparison, =<).
+value(K, V) :- raw_value(K, V).

package/conformance/cases/core/009_comments_and_whitespace.pl

@@ -2,3 +2,4 @@
   item(quoted_percent, "% not a comment").    % trailing comment
 item(quoted_atom, 'has % sign').
 answer(K, V) :- item(K, V).
+materialize(answer, 2).

package/conformance/cases/core/010_variable_scope_and_reuse.pl

@@ -5,3 +5,4 @@ edge(c, d).
 two_step(X, Z) :- edge(X, Y), edge(Y, Z).
 answer(from_a, Z) :- two_step(a, Z).
 answer(from_b, Z) :- two_step(b, Z).
+materialize(answer, 2).

package/conformance/cases/core/011_predicate_arity.pl

@@ -3,3 +3,4 @@ p(a).
 p(a, b).
 answer(unary, X) :- p(X).
 answer(binary, pair(X, Y)) :- p(X, Y).
+materialize(answer, 2).

package/conformance/cases/core/012_nested_compound_unification.pl

@@ -2,3 +2,4 @@
 fact(pair(a, nested(b, [c, d]))).
 answer(middle, X) :- fact(pair(a, nested(X, [c, d]))).
 answer(list_tail, T) :- fact(pair(a, nested(b, [c | T]))).
+materialize(answer, 2).

package/conformance/cases/core/013_multiple_clauses_order.pl

@@ -3,3 +3,4 @@ color(red).
 color(blue).
 paint(X) :- color(X).
 answer(color, X) :- paint(X).
+materialize(answer, 2).

package/conformance/cases/core/014_failure_filters_answers.pl

@@ -3,3 +3,5 @@ candidate(a).
 candidate(b).
 allowed(a).
 answer(X, ok) :- candidate(X), allowed(X).
+
+materialize(answer, 2).

package/conformance/cases/core/015_improper_list_unification.pl

@@ -3,3 +3,4 @@ cell([head | tail], head, tail).
 answer(list, L) :- cell(L, head, tail).
 answer(head, H) :- cell([H | tail], H, tail).
 answer(tail, T) :- cell([head | T], head, T).
+materialize(answer, 2).

package/conformance/cases/core/016_zero_arity_compound.pl

@@ -1,3 +1,4 @@
 % SPEC 4, 5.3: zero-arity compounds are written and matched with parentheses.
 status(nil(), ok).
 answer(value, X) :- status(X, ok).
+materialize(answer, 2).

package/conformance/cases/core/017_three_step_recursion.pl

@@ -5,3 +5,4 @@ link(c, d).
 path(X, Y) :- link(X, Y).
 path(X, Z) :- link(X, Y), path(Y, Z).
 answer(reachable, X) :- path(a, X).
+materialize(answer, 2).

package/conformance/cases/core/018_quoted_atom_readback.pl

@@ -3,3 +3,4 @@ symbol('two words').
 symbol('needs''quote').
 symbol('').
 answer(symbol, X) :- symbol(X).
+materialize(answer, 2).

package/conformance/cases/core/019_parenthesized_three_conjuncts.pl

@@ -4,3 +4,4 @@ q(a).
 r(a).
 ok(X) :- (p(X), q(X), r(X)).
 answer(ok, X) :- ok(X).
+materialize(answer, 2).

package/conformance/cases/core/020_nested_list_terms.pl

@@ -2,3 +2,4 @@
 node([pair(a, b), pair(c, d)]).
 answer(first_key, X) :- node([pair(X, _), pair(c, d)]).
 answer(second_key, X) :- node([pair(a, b), pair(X, d)]).
+materialize(answer, 2).

package/conformance/cases/extension/001_default_derived_output.pl

@@ -1,4 +1,4 @@
-% SPEC 11: no-query output prints new ground binary derivations, not source facts.
+% SPEC 11: default output prints new ground binary derivations, not source facts.
 parent(pat, jan).
 parent(jan, emma).
 ancestor(X, Y) :- parent(X, Y).

package/conformance/cases/extension/002_materialize_focus.pl

@@ -1,4 +1,4 @@
-% SPEC 10.2, 11: materialize/2 restricts selected no-query predicate groups.
+% SPEC 10.2, 11: materialize/2 restricts selected default predicate groups.
 materialize(answer, 2).
 seed(a).
 helper(X, y) :- seed(X).

package/conformance/cases/extension/003_arithmetic_and_comparison.pl

@@ -9,3 +9,4 @@ answer(minimum, X) :- min(3, 9, X).
 answer(maximum, X) :- max(3, 9, X).
 answer(less_than, true) :- lt(3, 9).
 answer(greater_equal, true) :- ge(9, 9).
+materialize(answer, 2).

package/conformance/cases/extension/004_strings_and_atoms.pl

@@ -3,3 +3,4 @@ answer(atom_concat, X) :- atom_concat(eye, lang, X).
 answer(str_concat, X) :- str_concat("eye", "lang", X).
 answer(contains, true) :- contains("eyelang", "lang").
 answer(not_contains, true) :- not_contains("eyelang", "cat").
+materialize(answer, 2).

package/conformance/cases/extension/005_lists_aggregation_ordering.pl

@@ -7,3 +7,4 @@ answer(reverse, X) :- reverse([a, b, c], X).
 answer(length, N) :- length([a, b, c], N).
 answer(findall, X) :- findall(N, between(1, 3, N), X).
 answer(sort, X) :- sort([b, a, b], X).
+materialize(answer, 2).

package/conformance/cases/extension/006_formula_terms.pl

@@ -2,3 +2,4 @@
 formula((name(alice, "Alice"), knows(alice, bob))).
 answer(atom, A) :- formula(F), formula_atom(F, A).
 answer(binary, exposed(S, P, O)) :- formula(F), formula_binary(F, S, P, O).
+materialize(answer, 2).

package/conformance/cases/extension/007_negation_once_generators.pl

@@ -4,3 +4,4 @@ candidate(b).
 closed(b).
 answer(open, X) :- candidate(X), not(closed(X)).
 answer(first_between, X) :- once(between(2, 4, X)).
+materialize(answer, 2).

package/conformance/cases/extension/008_equality_and_inequality.pl

@@ -3,3 +3,4 @@ answer(eq_variable, X) :- eq(X, pair(a, [b, c])).
 answer(eq_nested, true) :- eq(pair(X, X), pair(same, same)).
 answer(neq_atoms, true) :- neq(alice, bob).
 answer(neq_structures, true) :- neq(pair(a), pair(a, b)).
+materialize(answer, 2).

package/conformance/cases/extension/009_list_relations.pl

@@ -3,3 +3,4 @@ answer(rest, X) :- rest([a, b, c], X).
 answer(select, selected(X, R)) :- select(X, [a, b], R).
 answer(not_member, true) :- not_member(c, [a, b]).
 answer(is_list, true) :- is_list([a, b]).
+materialize(answer, 2).

package/conformance/cases/extension/010_append_splits.pl

@@ -1,2 +1,3 @@
 % SPEC 9.7: append/3 can enumerate proper prefix/suffix splits.
 answer(split, split(A, B)) :- append(A, B, [a, b]).
+materialize(answer, 2).

package/conformance/cases/extension/011_matching_and_comparison.pl

@@ -4,3 +4,4 @@ answer(not_matches, true) :- not_matches("eyelang", "cat").
 answer(lex_lt, true) :- lt(alpha, beta).
 answer(lex_gt, true) :- gt(beta, alpha).
 answer(numeric_le, true) :- le(2, 2).
+materialize(answer, 2).

package/conformance/cases/extension/012_memoize_declaration.pl

@@ -1,6 +1,8 @@
 % SPEC 10.1: memoize/2 is a declaration and does not change answers.
-memoize(reach, 2).
+materialize(reach, 2).
+memoize(reach_any, 2).
 edge(a, b).
 edge(b, c).
-reach(X, Y) :- edge(X, Y).
-reach(X, Z) :- edge(X, Y), reach(Y, Z).
+reach_any(X, Y) :- edge(X, Y).
+reach_any(X, Z) :- edge(X, Y), reach_any(Y, Z).
+reach(a, Y) :- reach_any(a, Y).

package/conformance/cases/extension/013_numeric_functions.pl

@@ -6,3 +6,4 @@ answer(sin_zero, X) :- sin(0, X).
 answer(cos_zero, X) :- cos(0, X).
 answer(log_one, X) :- log(1, X).
 answer(float_division, X) :- div(7.0, 2.0, X).
+materialize(answer, 2).

package/conformance/cases/extension/014_between_enumeration.pl

@@ -1,2 +1,3 @@
 % SPEC 9.5: between/3 enumerates every integer in an inclusive range.
 answer(n, X) :- between(3, 5, X).
+materialize(answer, 2).

package/conformance/cases/extension/015_smallest_divisor.pl

@@ -1,2 +1,3 @@
 % SPEC 9.5: smallest_divisor_from/3 finds the first divisor at or above the start.
 answer(divisor, D) :- smallest_divisor_from(21, 2, D).
+materialize(answer, 2).