eyelang 1.7.17 → 2.0.0

package/examples/riemann-hypothesis.eye

@@ -1,110 +0,0 @@
-% Riemann hypothesis, as a finite eyelang check.
-%
-% This example does not prove the Riemann hypothesis.  It models the
-% finite statement: every non-trivial zero in the local catalogue has
-% real part 0.5.  A real proof would have to cover all non-trivial zeros,
-% not only the facts listed here.
-
-% Print the finite check summary and the per-zero audit rows.
-materialize(rh, 2).
-materialize(zero_check, 3).
-
-% --- Sample zero catalogue -------------------------------------------------
-%
-% The three z* entries stand for catalogued non-trivial zeros of the
-% Riemann zeta function.  The t* entry is a trivial zero, included to show
-% that the rules below deliberately exclude it from the RH check.
-
-zeta_zero(z1).
-real_part(z1, 0.5).
-imaginary_part(z1, 14.134725).
-source(z1, "first catalogued non-trivial zero in this example").
-
-zeta_zero(z2).
-real_part(z2, 0.5).
-imaginary_part(z2, 21.02204).
-source(z2, "second catalogued non-trivial zero in this example").
-
-zeta_zero(z3).
-real_part(z3, 0.5).
-imaginary_part(z3, 25.010858).
-source(z3, "third catalogued non-trivial zero in this example").
-
-zeta_zero(t1).
-trivial_zero(t1).
-real_part(t1, -2).
-imaginary_part(t1, 0).
-source(t1, "trivial zero, outside the non-trivial RH check").
-
-% --- Classification rules --------------------------------------------------
-%
-% A non-trivial zero is one of the catalogued zeta zeros that lies in the
-% critical strip 0 < real part < 1 and is not explicitly marked as trivial.
-
-in_critical_strip(?zero) :-
-  real_part(?zero, ?real),
-  gt(?real, 0),
-  lt(?real, 1).
-
-non_trivial_zero(?zero) :-
-  zeta_zero(?zero),
-  in_critical_strip(?zero),
-  not(trivial_zero(?zero)).
-
-% The RH condition for one zero: its real part is exactly one half.
-
-on_critical_line(?zero) :-
-  non_trivial_zero(?zero),
-  real_part(?zero, 0.5).
-
-% A finite counterexample would be a catalogued non-trivial zero whose real
-% part is not one half.
-
-off_critical_line(?zero) :-
-  non_trivial_zero(?zero),
-  real_part(?zero, ?real),
-  neq(?real, 0.5).
-
-catalog_has(non_trivial_zero) :-
-  non_trivial_zero(?_somezero).
-
-counterexample_found(yes) :-
-  off_critical_line(?_zero).
-
-% The finite catalogue supports RH exactly when it contains at least one
-% non-trivial zero and no catalogued counterexample.
-
-finite_catalog_supports_rh(yes) :-
-  catalog_has(non_trivial_zero),
-  not(counterexample_found(yes)).
-
-% --- Materialized audit output --------------------------------------------
-
-% These tiny support facts make the summary rows derived output rather than
-% source facts; eyelang intentionally does not reprint source facts.
-
-summary_row(scope, finite_catalog_only).
-summary_row(caveat, "finite catalogue evidence only; this is not a proof of RH").
-
-rh(?key, ?value) :-
-  summary_row(?key, ?value).
-
-rh(status, no_counterexample_in_catalog) :-
-  finite_catalog_supports_rh(yes).
-
-rh(status, counterexample_in_catalog) :-
-  counterexample_found(yes).
-
-zero_check(?zero, real_part, ?real) :-
-  non_trivial_zero(?zero),
-  real_part(?zero, ?real).
-
-zero_check(?zero, imaginary_part, ?imaginary) :-
-  non_trivial_zero(?zero),
-  imaginary_part(?zero, ?imaginary).
-
-zero_check(?zero, classification, on_critical_line) :-
-  on_critical_line(?zero).
-
-zero_check(?zero, classification, off_critical_line) :-
-  off_critical_line(?zero).

package/examples/route-planning.eye

@@ -1,33 +0,0 @@
-% Route planning with explicit route terms.
-%
-% This is the Eyelang version of the classic Paris-to-Nantes path example: the
-% facts describe one-way road links, and `path/2` derives both the endpoint pair
-% and a structured `go(..., ..., ...)` plan.  The plan is ordinary data, so the
-% route can be inspected, stored, or used by later rules.
-
-materialize(route_to_nantes, 2).
-table(path, 2).
-mode(path, 2, [in, out]).
-
-oneway(paris, orleans).
-oneway(paris, chartres).
-oneway(paris, amiens).
-oneway(orleans, blois).
-oneway(orleans, bourges).
-oneway(blois, tours).
-oneway(chartres, lemans).
-oneway(lemans, angers).
-oneway(lemans, tours).
-oneway(angers, nantes).
-
-% A direct edge is a one-step plan.
-path([?a, ?b], go(?a, ?b, goal)) :-
-  oneway(?a, ?b).
-
-% A longer path prepends one edge to the remaining plan.
-path([?a, ?c], go(?a, ?b, ?rest)) :-
-  oneway(?a, ?b),
-  path([?b, ?c], ?rest).
-
-route_to_nantes(?from, ?plan) :-
-  path([?from, nantes], ?plan).

package/examples/sat-solver-dpll.eye

@@ -1,88 +0,0 @@
-% DPLL-style SAT solving for a small CNF formula.
-%
-% The example keeps the solver itself in Eyelang.  It recursively assigns
-% variables in a fixed order, prunes a branch as soon as any clause is already
-% impossible, and accepts a complete assignment when every clause is satisfied.
-% aggregate_min/5 is then used only to choose one canonical satisfying model.
-
-materialize(satModel, 1).
-materialize(satValue, 2).
-materialize(satClauseStatus, 2).
-materialize(satConclusion, 2).
-
-% CNF formula:
-%   (a or b)
-%   (not a or c)
-%   (not b or c)
-%   (not c or d)
-%   (c or not d)
-variable_order([a, b, c, d]).
-clause(c1, [pos(a), pos(b)]).
-clause(c2, [neg(a), pos(c)]).
-clause(c3, [neg(b), pos(c)]).
-clause(c4, [neg(c), pos(d)]).
-clause(c5, [pos(c), neg(d)]).
-
-bool(false).
-bool(true).
-bit(false, 0).
-bit(true, 1).
-
-% Look up a variable inside a partial or complete assignment represented as a
-% list of bind(Name, Bool) terms.
-lookup_bool(?name, [bind(?name, ?value) | ?], ?value).
-lookup_bool(?name, [bind(?, ?) | ?rest], ?value) :- lookup_bool(?name, ?rest, ?value).
-
-literal_true(pos(?var), ?assignment) :- lookup_bool(?var, ?assignment, true).
-literal_true(neg(?var), ?assignment) :- lookup_bool(?var, ?assignment, false).
-literal_false(pos(?var), ?assignment) :- lookup_bool(?var, ?assignment, false).
-literal_false(neg(?var), ?assignment) :- lookup_bool(?var, ?assignment, true).
-
-clause_satisfied(?assignment, ?clause_name) :-
-  clause(?clause_name, ?literals),
-  member(?literal, ?literals),
-  literal_true(?literal, ?assignment).
-
-% A partial branch is impossible when every literal in a clause is already false.
-% Unassigned literals keep the branch alive, just as in DPLL.
-clause_impossible(?assignment, ?clause_name) :-
-  clause(?clause_name, ?literals),
-  forall(member(?literal, ?literals), literal_false(?literal, ?assignment)).
-partial_consistent(?assignment) :- not((clause(?name, ?), clause_impossible(?assignment, ?name))).
-complete_model(?assignment) :- forall(clause(?name, ?), clause_satisfied(?assignment, ?name)).
-
-% Recursive DPLL search: choose a truth value, prune if inconsistent, then
-% continue with the remaining variables.
-dpll([], ?assignment, ?assignment) :- complete_model(?assignment).
-dpll([?var | ?rest], ?partial, ?model) :-
-  bool(?value),
-  partial_consistent([bind(?var, ?value) | ?partial]),
-  dpll(?rest, [bind(?var, ?value) | ?partial], ?model).
-
-satisfying_model(?model) :- variable_order(?vars), dpll(?vars, [], ?model).
-
-% Rank models so the materialized output shows one deterministic answer.  The
-% model list is in reverse decision order because each decision is pushed onto
-% the front during recursion.
-model_rank(?model, ?rank) :-
-  lookup_bool(a, ?model, ?a), bit(?a, ?abit),
-  lookup_bool(b, ?model, ?b), bit(?b, ?bbit),
-  lookup_bool(c, ?model, ?c), bit(?c, ?cbit),
-  lookup_bool(d, ?model, ?d), bit(?d, ?dbit),
-  mul(?abit, 8, ?arank),
-  mul(?bbit, 4, ?brank),
-  mul(?cbit, 2, ?crank),
-  add(?arank, ?brank, ?ab),
-  add(?crank, ?dbit, ?cd),
-  add(?ab, ?cd, ?rank).
-
-best_model(?model, ?rank) :-
-  aggregate_min(?candidate_rank, ?candidate_model,
-    (satisfying_model(?candidate_model), model_rank(?candidate_model, ?candidate_rank)),
-    ?rank, ?model).
-
-satModel(?model) :- best_model(?model, ?).
-satValue(?var, ?value) :- best_model(?model, ?), lookup_bool(?var, ?model, ?value).
-satClauseStatus(?clause, satisfied) :- best_model(?model, ?), clause_satisfied(?model, ?clause).
-satConclusion(case, "DPLL finds a satisfying assignment after pruning clauses that become impossible") :-
-  best_model(?, ?).

package/examples/security-incident-correlation.eye

@@ -1,69 +0,0 @@
-% Representative example: security incident correlation.
-%
-% The rules correlate endpoint, identity, vulnerability, and threat-intelligence
-% signals into an escalation decision with concise reason relations.
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-materialize(type, 2).
-materialize(status, 2).
-materialize(reason, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-incident(inc42).
-incident(inc43).
-
-asset(endpoint23, criticality, high).
-asset(endpoint77, criticality, low).
-
-assigned_user(endpoint23, user_alice).
-assigned_user(endpoint77, user_bob).
-
-privileged_user(user_alice).
-
-alert(inc42, endpoint, endpoint23).
-alert(inc42, suspicious_login, user_alice).
-alert(inc42, malware_hash, hash_redline).
-alert(inc42, outbound_ip, ip_203_0_113_17).
-
-alert(inc43, endpoint, endpoint77).
-alert(inc43, suspicious_login, user_bob).
-alert(inc43, outbound_ip, ip_198_51_100_42).
-
-vulnerability(endpoint23, cve_critical_rce).
-threat_intel(ip_203_0_113_17, command_and_control).
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-critical_asset(?endpoint) :-
-  asset(?endpoint, criticality, high).
-
-credential_abuse(?incident) :-
-  alert(?incident, suspicious_login, ?user),
-  privileged_user(?user).
-
-malware_on_critical_asset(?incident) :-
-  alert(?incident, endpoint, ?endpoint),
-  alert(?incident, malware_hash, ?_hash),
-  critical_asset(?endpoint).
-
-c2_contact(?incident) :-
-  alert(?incident, outbound_ip, ?ip),
-  threat_intel(?ip, command_and_control).
-
-exploitable_endpoint(?incident) :-
-  alert(?incident, endpoint, ?endpoint),
-  vulnerability(?endpoint, cve_critical_rce).
-
-confirmed_compromise(?incident) :-
-  credential_abuse(?incident),
-  malware_on_critical_asset(?incident),
-  c2_contact(?incident),
-  exploitable_endpoint(?incident).
-
-type(?incident, confirmed_compromise) :-
-  confirmed_compromise(?incident).
-
-status(?incident, escalate_to_incident_response) :-
-  confirmed_compromise(?incident).
-
-reason(?incident, "privileged credential abuse, malware on a critical endpoint, C2 contact, and exploitable RCE are correlated") :-
-  confirmed_compromise(?incident).

package/examples/send-more-money.eye

@@ -1,71 +0,0 @@
-% Cryptarithm search for SEND + MORE = MONEY.
-%
-% The solver assigns distinct decimal digits to letters while enforcing the
-% column-by-column carries.  Rather than generate all digit assignments first,
-% each column constraint is applied as soon as its letters are chosen.
-materialize(cryptarithm_answer, 2).
-
-% The search domain is a shrinking digit list threaded through select/3 calls.
-all_digits([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]).
-
-send_more_money(solution(?s, ?e, ?n, ?d, ?m, ?o, ?r, ?y)) :-
-  all_digits(?digits),
-  eq(?m, 1),
-  eq(?o, 0),
-  select(?m, ?digits, ?d0),
-  select(?o, ?d0, ?d1),
-
-  select(?d, ?d1, ?d2),
-  select(?e, ?d2, ?d3),
-  add(?d, ?e, ?onessum),
-  mod(?onessum, 10, ?y),
-  div(?onessum, 10, ?carry1),
-  select(?y, ?d3, ?d4),
-
-  select(?n, ?d4, ?d5),
-  select(?r, ?d5, ?d6),
-  add(?n, ?r, ?tenspartial),
-  add(?tenspartial, ?carry1, ?tenssum),
-  mod(?tenssum, 10, ?e),
-  div(?tenssum, 10, ?carry2),
-
-  add(?e, ?o, ?hundredspartial),
-  add(?hundredspartial, ?carry2, ?hundredssum),
-  mod(?hundredssum, 10, ?n),
-  div(?hundredssum, 10, ?carry3),
-
-  select(?s, ?d6, ?_d7),
-  neq(?s, 0),
-  add(?s, ?m, ?thousandspartial),
-  add(?thousandspartial, ?carry3, ?thousandssum),
-  mod(?thousandssum, 10, ?o),
-  div(?thousandssum, 10, ?m).
-
-% Number constructors are used only for readable output after a solution is found.
-number4(?a, ?b, ?c, ?d, ?value) :-
-  mul(?a, 1000, ?apart),
-  mul(?b, 100, ?bpart),
-  mul(?c, 10, ?cpart),
-  add(?apart, ?bpart, ?ab),
-  add(?ab, ?cpart, ?abc),
-  add(?abc, ?d, ?value).
-
-number5(?a, ?b, ?c, ?d, ?e, ?value) :-
-  mul(?a, 10000, ?apart),
-  mul(?b, 1000, ?bpart),
-  mul(?c, 100, ?cpart),
-  mul(?d, 10, ?dpart),
-  add(?apart, ?bpart, ?ab),
-  add(?ab, ?cpart, ?abc),
-  add(?abc, ?dpart, ?abcd),
-  add(?abcd, ?e, ?value).
-
-cryptarithm_answer(assignments, solution(?s, ?e, ?n, ?d, ?m, ?o, ?r, ?y)) :-
-  send_more_money(solution(?s, ?e, ?n, ?d, ?m, ?o, ?r, ?y)).
-cryptarithm_answer(equation, equation(?send, ?more, ?money)) :-
-  send_more_money(solution(?s, ?e, ?n, ?d, ?m, ?o, ?r, ?y)),
-  number4(?s, ?e, ?n, ?d, ?send),
-  number4(?m, ?o, ?r, ?e, ?more),
-  number5(?m, ?o, ?n, ?e, ?y, ?money).
-cryptarithm_answer(solution_count, ?count) :-
-  countall(send_more_money(?_solution), ?count).

package/examples/service-impact.eye

@@ -1,41 +0,0 @@
-% Practical cyclic recursion: incident impact analysis for a service dependency graph.
-% The payment stack has a real-world feedback cycle: payment_service calls
-% fraud_service, fraud_service calls risk_rules, and risk_rules calls payment_service
-% for authorization data. A payment outage should still produce a finite impact set.
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-materialize(impactedByFailureOf, 2).
-materialize(status, 2).
-materialize(businessFunctionAtRisk, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-depends_on(web_store, checkout_api).
-depends_on(mobile_app, checkout_api).
-depends_on(checkout_api, payment_service).
-depends_on(checkout_api, inventory_service).
-depends_on(payment_service, fraud_service).
-depends_on(fraud_service, risk_rules).
-depends_on(risk_rules, payment_service).
-depends_on(inventory_service, stock_db).
-depends_on(stock_db, inventory_service).
-
-business_function(place_order, web_store).
-business_function(mobile_checkout, mobile_app).
-business_function(collect_payment, payment_service).
-business_function(screen_fraud, fraud_service).
-business_function(show_stock, inventory_service).
-
-failed(payment_service).
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-impacted(?service, ?failed) :- depends_on(?service, ?failed).
-impacted(?service, ?failed) :- depends_on(?service, ?dependency), impacted(?dependency, ?failed).
-
-affected(?service) :- failed(?failed), impacted(?service, ?failed).
-affected(?service) :- failed(?service).
-
-affected_function(?function) :- business_function(?function, ?service), affected(?service).
-
-impactedByFailureOf(?service, ?failed) :- failed(?failed), impacted(?service, ?failed).
-status(?service, failed) :- failed(?service).
-businessFunctionAtRisk(?function, true) :- affected_function(?function).

package/examples/shoelace-polygon-area.eye

@@ -1,22 +0,0 @@
-% Polygon area by the shoelace formula.
-%
-% The input polygon is the same closed polygon shape used by the source example:
-% the final point repeats the first point.  Each recursive step consumes one
-% adjacent pair and contributes `(x1*y2 - y1*x2) / 2` to the oriented area.
-
-materialize(polygon_area, 2).
-
-sample_polygon([[3, 2], [6, 2], [7, 6], [4, 6], [5, 5], [5, 3], [3, 2]]).
-
-area([?_point], 0).
-area([[?a, ?b], [?c, ?d]|?rest], ?total) :-
-  area([[?c, ?d]|?rest], ?subtotal),
-  mul(?a, ?d, ?ad),
-  mul(?b, ?c, ?bc),
-  sub(?ad, ?bc, ?cross),
-  div(?cross, 2.0, ?half),
-  add(?half, ?subtotal, ?total).
-
-polygon_area(sample, ?area) :-
-  sample_polygon(?points),
-  area(?points, ?area).

package/examples/sieve.eye

@@ -1,20 +0,0 @@
-% Prime enumeration inspired by Eyelet input/sieve.eye.
-% The 1000-limit answer matches Eyelet output-swipl/sieve.eye.
-%
-% eyelang uses the built-in smallest_divisor_from/3 relation to keep the
-% example fast while preserving the same generated prime list.
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-materialize(primes, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-want_primes(1000).
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-prime_under(?limit, ?p) :-
-  between(2, ?limit, ?p),
-  smallest_divisor_from(?p, 2, ?p).
-
-primes(?limit, ?ps) :-
-  want_primes(?limit),
-  findall(?p, prime_under(?limit, ?p), ?ps).

package/examples/skolem-functions.eye

@@ -1,52 +0,0 @@
-% Skolem functional terms in rule heads.
-%
-% A generated resource should be deterministic and collision-free. Use a
-% function symbol whose arguments contain the values that make the resource
-% unique, such as skolem_observation(Patient, Test).
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-materialize(type, 2).
-materialize(patient, 2).
-materialize(test, 2).
-materialize(value, 2).
-materialize(about, 2).
-materialize(sameInputsSameId, 2).
-materialize(noObservationClash, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-test_result(alice, glucose, 6.8).
-test_result(alice, cholesterol, 4.2).
-test_result(bob, glucose, 5.1).
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-high_glucose(?patient) :-
-  test_result(?patient, glucose, ?value),
-  gt(?value, 6.0).
-
-observation_id(?patient, ?test, skolem_observation(?patient, ?test)) :-
-  test_result(?patient, ?test, ?_value).
-
-type(skolem_observation(?patient, ?test), observation) :-
-  test_result(?patient, ?test, ?_value).
-
-patient(skolem_observation(?patient, ?test), ?patient) :-
-  test_result(?patient, ?test, ?_value).
-
-test(skolem_observation(?patient, ?test), ?test) :-
-  test_result(?patient, ?test, ?_value).
-
-value(skolem_observation(?patient, ?test), ?value) :-
-  test_result(?patient, ?test, ?value).
-
-type(skolem_alert(?patient, glucose), highGlucoseAlert) :-
-  high_glucose(?patient).
-
-about(skolem_alert(?patient, glucose), skolem_observation(?patient, glucose)) :-
-  high_glucose(?patient).
-
-sameInputsSameId(skolemDemo, true) :-
-  eq(skolem_observation(alice, glucose), skolem_observation(alice, glucose)).
-
-noObservationClash(skolemDemo, true) :-
-  neq(skolem_observation(alice, glucose), skolem_observation(alice, cholesterol)),
-  neq(skolem_observation(alice, glucose), skolem_observation(bob, glucose)).

package/examples/socket-age.eye

@@ -1,39 +0,0 @@
-% socket-age.eye
-%
-% A small runnable eyelang Socket example for age reasoning.
-%
-% The socket facts are ordinary eyelang data. They document the semantic
-% openings that this rule module expects:
-%
-%   - a patient registry that provides birthDay/2
-%   - a policy source that provides duration/2
-%   - a clock source that provides today/1
-%
-% The plug facts say which concrete providers are connected.
-%
-% Run:
-%   eyelang socket-age.eye
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-materialize(ageAbove, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-socket(patient_registry, provides(birthDay_2)).
-socket(policy_source, provides(duration_2)).
-socket(clock_source, provides(today_1)).
-
-plug(test_patients, patient_registry).
-plug(test_policy, policy_source).
-plug(test_clock, clock_source).
-
-birthDay(patH, "1944-08-21").
-duration(check, "P80Y").
-today("2026-05-30").
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-ageAbove(?s, ?a) :-
-    birthDay(?s, ?b),
-    duration(check, ?a),
-    today(?d),
-    difference(?d, ?b, ?f),
-    gt(?f, ?a).

package/examples/socket-family.eye

@@ -1,28 +0,0 @@
-% socket-family.eye
-%
-% A small runnable eyelang Socket example.
-%
-% The socket facts below are ordinary eyelang data. They document the
-% semantic opening: this reasoning module expects a provider for parent/2.
-% The plug fact says which provider is connected.
-%
-% Run:
-%   eyelang socket-family.eye
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-materialize(ancestor, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-socket(family_source, provides(parent_2)).
-plug(family_file, family_source).
-
-parent(pat, jan).
-parent(jan, emma).
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-ancestor(?x, ?y) :-
-    parent(?x, ?y).
-
-ancestor(?x, ?z) :-
-    parent(?x, ?y),
-    ancestor(?y, ?z).

package/examples/socrates.eye

@@ -1,19 +0,0 @@
-% Socrates is mortal, adapted from Eyelet's input/socrates.eye.
-%
-% Eyelet uses type('Socrates', 'Man') and a single rule deriving Mortal.
-% eyelang keeps the same reasoning shape and emits relation facts.
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-materialize(type, 2).
-materialize(is, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-type(socrates, man).
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-type(?x, mortal) :-
-  type(?x, man).
-
-
-is(test, true) :-
-  type(socrates, mortal).

package/examples/stable-marriage.eye

@@ -1,92 +0,0 @@
-% Stable-marriage search with explicit blocking-pair detection.
-%
-% matching/1 enumerates one-to-one pairings for four men and four women.  A
-% pairing is stable precisely when no blocking pair exists: two people who would
-% both prefer each other over their assigned partners.
-materialize(stable_marriage_answer, 2).
-
-man(adam).
-man(brian).
-man(cole).
-man(drew).
-
-woman(amy).
-woman(bea).
-woman(cora).
-woman(dana).
-
-rank_man(adam, bea, 1).
-rank_man(adam, amy, 2).
-rank_man(adam, dana, 3).
-rank_man(adam, cora, 4).
-rank_man(brian, amy, 1).
-rank_man(brian, cora, 2).
-rank_man(brian, bea, 3).
-rank_man(brian, dana, 4).
-rank_man(cole, amy, 1).
-rank_man(cole, bea, 2).
-rank_man(cole, dana, 3).
-rank_man(cole, cora, 4).
-rank_man(drew, cora, 1).
-rank_man(drew, dana, 2).
-rank_man(drew, bea, 3).
-rank_man(drew, amy, 4).
-
-rank_woman(amy, cole, 1).
-rank_woman(amy, adam, 2).
-rank_woman(amy, brian, 3).
-rank_woman(amy, drew, 4).
-rank_woman(bea, adam, 1).
-rank_woman(bea, cole, 2).
-rank_woman(bea, drew, 3).
-rank_woman(bea, brian, 4).
-rank_woman(cora, drew, 1).
-rank_woman(cora, brian, 2).
-rank_woman(cora, adam, 3).
-rank_woman(cora, cole, 4).
-rank_woman(dana, brian, 1).
-rank_woman(dana, drew, 2).
-rank_woman(dana, cole, 3).
-rank_woman(dana, adam, 4).
-
-% Permutations give every complete one-to-one matching over the four women.
-perm([], []).
-perm(?items, [?x|?rest]) :-
-  select(?x, ?items, ?remaining),
-  perm(?remaining, ?rest).
-
-matching([
-  pair(adam, ?w1),
-  pair(brian, ?w2),
-  pair(cole, ?w3),
-  pair(drew, ?w4)
-]) :-
-  perm([amy, bea, cora, dana], [?w1, ?w2, ?w3, ?w4]).
-
-assigned(?matching, ?man, ?woman) :- member(pair(?man, ?woman), ?matching).
-
-prefers_man(?man, ?candidate, ?current) :-
-  rank_man(?man, ?candidate, ?candidaterank),
-  rank_man(?man, ?current, ?currentrank),
-  lt(?candidaterank, ?currentrank).
-
-prefers_woman(?woman, ?candidate, ?current) :-
-  rank_woman(?woman, ?candidate, ?candidaterank),
-  rank_woman(?woman, ?current, ?currentrank),
-  lt(?candidaterank, ?currentrank).
-
-% A blocking pair witnesses instability of a candidate matching.
-blocking_pair(?matching, ?man, ?woman) :-
-  assigned(?matching, ?man, ?currentwoman),
-  woman(?woman),
-  neq(?woman, ?currentwoman),
-  prefers_man(?man, ?woman, ?currentwoman),
-  assigned(?matching, ?currentman, ?woman),
-  prefers_woman(?woman, ?man, ?currentman).
-
-stable_matching(?matching) :-
-  matching(?matching),
-  not(blocking_pair(?matching, ?_man, ?_woman)).
-
-stable_marriage_answer(first_stable_matching, ?matching) :- once(stable_matching(?matching)).
-stable_marriage_answer(stable_matching_count, ?count) :- countall(stable_matching(?_matching), ?count).