eyelang 1.2.2 → 1.3.1

package/examples/hamming-code.eye

@@ -0,0 +1,109 @@
+% Technology example: Hamming(7,4) single-bit error correction.
+%
+% The received word has one corrupted bit. Syndrome bits identify the bad
+% position, then the corrected codeword and decoded payload are derived.
+
+% Output declarations: materialize/2 selects the relations written to this example's golden output.
+%
+% Positions are one-based to match the textbook parity-check layout. The
+% syndrome value is both the error certificate and the index of the bit to fix.
+materialize(syndrome, 2).
+materialize(errorBit, 2).
+materialize(correctedCodeword, 2).
+materialize(decodedPayload, 2).
+materialize(status, 2).
+materialize(reason, 2).
+
+% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
+received_bit(packet1, 1, 1).
+received_bit(packet1, 2, 0).
+received_bit(packet1, 3, 1).
+received_bit(packet1, 4, 1).
+received_bit(packet1, 5, 1).
+received_bit(packet1, 6, 1).
+received_bit(packet1, 7, 0).
+
+flip(0, 1).
+flip(1, 0).
+
+% Derivation rules: each rule below contributes one logical step toward the displayed results.
+parity4(?a, ?b, ?c, ?d, ?parity) :-
+  add(?a, ?b, ?ab),
+  add(?ab, ?c, ?abc),
+  add(?abc, ?d, ?sum),
+  mod(?sum, 2, ?parity).
+
+syndrome_bit1(?code, ?s1) :-
+  received_bit(?code, 1, ?b1),
+  received_bit(?code, 3, ?b3),
+  received_bit(?code, 5, ?b5),
+  received_bit(?code, 7, ?b7),
+  parity4(?b1, ?b3, ?b5, ?b7, ?s1).
+
+syndrome_bit2(?code, ?s2) :-
+  received_bit(?code, 2, ?b2),
+  received_bit(?code, 3, ?b3),
+  received_bit(?code, 6, ?b6),
+  received_bit(?code, 7, ?b7),
+  parity4(?b2, ?b3, ?b6, ?b7, ?s2).
+
+syndrome_bit4(?code, ?s4) :-
+  received_bit(?code, 4, ?b4),
+  received_bit(?code, 5, ?b5),
+  received_bit(?code, 6, ?b6),
+  received_bit(?code, 7, ?b7),
+  parity4(?b4, ?b5, ?b6, ?b7, ?s4).
+
+% syndrome/2 combines parity checks as S1 + 2*S2 + 4*S4.
+syndrome(?code, ?syndrome) :-
+  syndrome_bit1(?code, ?s1),
+  syndrome_bit2(?code, ?s2),
+  syndrome_bit4(?code, ?s4),
+  mul(?s2, 2, ?weighteds2),
+  mul(?s4, 4, ?weighteds4),
+  add(?s1, ?weighteds2, ?partial),
+  add(?partial, ?weighteds4, ?syndrome).
+
+corrected_bit(?code, ?position, ?corrected) :-
+  syndrome(?code, ?position),
+  received_bit(?code, ?position, ?bit),
+  flip(?bit, ?corrected).
+
+corrected_bit(?code, ?position, ?bit) :-
+  syndrome(?code, ?errorposition),
+  neq(?position, ?errorposition),
+  received_bit(?code, ?position, ?bit).
+
+corrected_codeword(?code, [?b1, ?b2, ?b3, ?b4, ?b5, ?b6, ?b7]) :-
+  corrected_bit(?code, 1, ?b1),
+  corrected_bit(?code, 2, ?b2),
+  corrected_bit(?code, 3, ?b3),
+  corrected_bit(?code, 4, ?b4),
+  corrected_bit(?code, 5, ?b5),
+  corrected_bit(?code, 6, ?b6),
+  corrected_bit(?code, 7, ?b7).
+
+decoded_payload(?code, [?d1, ?d2, ?d3, ?d4]) :-
+  corrected_bit(?code, 3, ?d1),
+  corrected_bit(?code, 5, ?d2),
+  corrected_bit(?code, 6, ?d3),
+  corrected_bit(?code, 7, ?d4).
+
+
+errorBit(?code, ?position) :-
+  syndrome(?code, ?position),
+  gt(?position, 0).
+
+correctedCodeword(?code, ?codeword) :-
+  corrected_codeword(?code, ?codeword).
+
+decodedPayload(?code, ?payload) :-
+  decoded_payload(?code, ?payload).
+
+status(?code, single_bit_corrected) :-
+  syndrome(?code, ?position),
+  gt(?position, 0).
+
+reason(?code, "Hamming syndrome identifies the flipped bit position") :-
+  syndrome(?code, ?position),
+  gt(?position, 0).

package/examples/hanoi.eye

@@ -0,0 +1,19 @@
+% Towers of Hanoi adapted from Eyeling hanoi.n3.
+% hanoi/5 recursively builds the move list by moving N-1 disks aside, moving the
+% largest disk, then moving N-1 disks onto the target peg.  The size-3 answer is
+% small enough for a readable golden output while still exercising list append.
+
+materialize(answer, 2).
+
+table(hanoi, 5).
+
+hanoi(0, ?_from, ?_to, ?_via, []).
+hanoi(?n, ?from, ?to, ?via, ?moves) :-
+  gt(?n, 0),
+  sub(?n, 1, ?n1),
+  hanoi(?n1, ?from, ?via, ?to, ?before),
+  hanoi(?n1, ?via, ?to, ?from, ?after),
+  append(?before, [[?from, ?to]|?after], ?moves).
+
+answer(3, ?moves) :-
+  hanoi(3, left, right, center, ?moves).

package/examples/heat-loss.eye

@@ -0,0 +1,56 @@
+% Engineering example: one-dimensional conductive heat loss through a wall.
+%
+% Thermal resistance is L/(k*A), and heat loss is DeltaT/R.  The facts store wall
+% properties as a small attribute table, while rules derive temperature
+% difference, resistance, heat loss, and a qualitative status.
+%
+% Keeping each physical quantity as its own relation makes the proof explanation
+% read like a worked calculation.
+materialize(type, 2).
+materialize(temperatureDifference_K, 2).
+materialize(thermalResistance_K_W, 2).
+materialize(heatLoss_W, 2).
+materialize(status, 2).
+
+% Wall properties are stored as key/value facts: conductivity, area, thickness,
+% and inside/outside temperatures.
+wall(wall1, conductivity_W_mK, 0.8).
+wall(wall1, area_m2, 12.0).
+wall(wall1, thickness_m, 0.2).
+wall(wall1, indoor_C, 21.0).
+wall(wall1, outdoor_C, -4.0).
+
+% The model first derives the temperature difference and thermal resistance,
+% then divides DeltaT by resistance to classify the heat loss.
+temperature_difference(?wall, ?deltat) :-
+  wall(?wall, indoor_C, ?indoor),
+  wall(?wall, outdoor_C, ?outdoor),
+  sub(?indoor, ?outdoor, ?deltat).
+
+thermal_resistance(?wall, ?resistance) :-
+  wall(?wall, thickness_m, ?thickness),
+  wall(?wall, conductivity_W_mK, ?conductivity),
+  wall(?wall, area_m2, ?area),
+  mul(?conductivity, ?area, ?conductance),
+  div(?thickness, ?conductance, ?resistance).
+
+heat_loss(?wall, ?heatloss) :-
+  temperature_difference(?wall, ?deltat),
+  thermal_resistance(?wall, ?resistance),
+  div(?deltat, ?resistance, ?heatloss).
+
+type(?wall, conduction_heat_loss) :-
+  wall(?wall, thickness_m, ?_thickness).
+
+temperatureDifference_K(?wall, ?deltat) :-
+  temperature_difference(?wall, ?deltat).
+
+thermalResistance_K_W(?wall, ?resistance) :-
+  thermal_resistance(?wall, ?resistance).
+
+heatLoss_W(?wall, ?heatloss) :-
+  heat_loss(?wall, ?heatloss).
+
+status(?wall, high_heat_loss) :-
+  heat_loss(?wall, ?heatloss),
+  gt(?heatloss, 1000.0).

package/examples/heron-theorem.eye

@@ -0,0 +1,42 @@
+% Heron's theorem: area = sqrt(s(s-a)(s-b)(s-c)).
+%
+% The sample is the classic 13-14-15 triangle, whose area is exactly 84.  The
+% program materializes the semiperimeter, Heron product, and final area so proof
+% output can be checked against the familiar hand calculation.
+%
+% This is a compact example of theorem-shaped arithmetic: facts name a geometric
+% object, reusable relations compute intermediates, and wrapper predicates choose
+% the report vocabulary.
+materialize(semiperimeter, 2).
+materialize(heronProduct, 2).
+materialize(area, 2).
+materialize(status, 2).
+
+% A single survey triangle is enough to demonstrate the formula; 13-14-15 has
+% integer area 84, which makes the computed result easy to check.
+triangle(field_plot, 13, 14, 15).
+
+% semiperimeter/2 is the reusable first step in Heron's formula.
+semiperimeter(?triangle, ?s) :-
+  triangle(?triangle, ?a, ?b, ?c),
+  add(?a, ?b, ?ab),
+  add(?ab, ?c, ?sum),
+  div(?sum, 2, ?s).
+
+% Area is obtained by taking the square root of this Heron product.
+heron_product(?triangle, ?product) :-
+  triangle(?triangle, ?a, ?b, ?c),
+  semiperimeter(?triangle, ?s),
+  sub(?s, ?a, ?sa),
+  sub(?s, ?b, ?sb),
+  sub(?s, ?c, ?sc),
+  mul(?s, ?sa, ?t1),
+  mul(?t1, ?sb, ?t2),
+  mul(?t2, ?sc, ?product).
+
+area(?triangle, ?area) :-
+  heron_product(?triangle, ?product),
+  pow(?product, 0.5, ?area).
+
+heronProduct(?triangle, ?p) :- heron_product(?triangle, ?p).
+status(?triangle, valid_survey_triangle) :- area(?triangle, ?a), gt(?a, 0).

package/examples/ideal-gas-law.eye

@@ -0,0 +1,39 @@
+% Science example: ideal gas law.
+%
+% A simple gas cell uses P*V = n*R*T.  The constants are chosen so that the
+% computed pressure is exactly near one atmosphere in this small example.
+
+% Output declarations: materialize/2 selects the relations written to this example's golden output.
+materialize(pressure_Pa, 2).
+materialize(status, 2).
+materialize(reason, 2).
+
+% gas_cell/5 records n, R, T, and V; pressure_limit/3 gives the tolerance band
+% used to classify the result as near atmospheric.
+gas_cell(cell1, 1.0, 8.0, 300.0, 0.024).
+pressure_limit(cell1, low_Pa, 95000.0).
+pressure_limit(cell1, high_Pa, 105000.0).
+
+% pressure/2 computes nRT/V in three explicit arithmetic steps so the proof
+% output exposes numerator construction and final division.
+pressure(?cell, ?pressure) :-
+  gas_cell(?cell, ?moles, ?gasconstant, ?temperature, ?volume),
+  mul(?moles, ?gasconstant, ?nr),
+  mul(?nr, ?temperature, ?nrt),
+  div(?nrt, ?volume, ?pressure).
+
+near_atmospheric(?cell) :-
+  pressure(?cell, ?pressure),
+  pressure_limit(?cell, low_Pa, ?low),
+  pressure_limit(?cell, high_Pa, ?high),
+  gt(?pressure, ?low),
+  lt(?pressure, ?high).
+
+pressure_Pa(?cell, ?pressure) :-
+  pressure(?cell, ?pressure).
+
+status(?cell, near_atmospheric) :-
+  near_atmospheric(?cell).
+
+reason(?cell, "pressure is inside the one-atmosphere tolerance band") :-
+  near_atmospheric(?cell).

package/examples/illegitimate-reasoning.eye

@@ -0,0 +1,88 @@
+% Illegitimate reasoning detector.
+%
+% The input facts describe arguments and their surface reasoning pattern. Helper
+% predicates identify common invalid inference forms. The output layer emits only
+% concise report relations: the argument is illegitimate, which fallacy was found,
+% the challenged conclusion, and a short reason why.
+
+% Affirming the consequent:
+%   If it rained, the street is wet. The street is wet. Therefore it rained.
+% Output declarations: materialize/2 selects the relations written to this example's golden output.
+materialize(type, 2).
+materialize(fallacy, 2).
+materialize(conclusion, 2).
+materialize(reason, 2).
+materialize(sampleSize, 2).
+materialize(requiredSampleSize, 2).
+materialize(omittedAlternative, 2).
+
+% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
+argument(arg_affirming_consequent).
+implication(arg_affirming_consequent, rain, street_wet).
+observed(arg_affirming_consequent, street_wet).
+concludes(arg_affirming_consequent, rain).
+
+% Denying the antecedent:
+%   If the key is present, the door opens. The key is not present. Therefore the door does not open.
+argument(arg_denying_antecedent).
+implication(arg_denying_antecedent, key_present, door_opens).
+observed(arg_denying_antecedent, neg(key_present)).
+concludes(arg_denying_antecedent, neg(door_opens)).
+
+% Hasty generalization:
+%   Three sampled cases are treated as enough for a universal conclusion.
+argument(arg_hasty_generalization).
+sample_size(arg_hasty_generalization, 3).
+required_sample_size(arg_hasty_generalization, 30).
+concludes(arg_hasty_generalization, all(crows, black)).
+
+% False dilemma:
+%   Only two choices are presented even though a relevant third option exists.
+argument(arg_false_dilemma).
+presented_alternatives(arg_false_dilemma, [approve_now, reject_forever]).
+omitted_alternative(arg_false_dilemma, revise_proposal).
+concludes(arg_false_dilemma, approve_now).
+
+% A contrast case: modus ponens is not flagged.
+argument(arg_modus_ponens).
+implication(arg_modus_ponens, subscription_paid, access_allowed).
+observed(arg_modus_ponens, subscription_paid).
+concludes(arg_modus_ponens, access_allowed).
+
+% Derivation rules: each rule below contributes one logical step toward the displayed results.
+fallacy(?a, affirming_consequent) :-
+  argument(?a),
+  implication(?a, ?antecedent, ?consequent),
+  observed(?a, ?consequent),
+  concludes(?a, ?antecedent).
+
+fallacy(?a, denying_antecedent) :-
+  argument(?a),
+  implication(?a, ?antecedent, ?consequent),
+  observed(?a, neg(?antecedent)),
+  concludes(?a, neg(?consequent)).
+
+fallacy(?a, hasty_generalization) :-
+  argument(?a),
+  sample_size(?a, ?n),
+  required_sample_size(?a, ?min),
+  lt(?n, ?min),
+  concludes(?a, all(?_, ?_)).
+
+fallacy(?a, false_dilemma) :-
+  argument(?a),
+  presented_alternatives(?a, ?_),
+  omitted_alternative(?a, ?_),
+  concludes(?a, ?_).
+
+reason(arg_affirming_consequent, "observing the consequent does not prove the antecedent").
+reason(arg_denying_antecedent, "denying the antecedent does not disprove the consequent").
+reason(arg_hasty_generalization, "sample size is below the threshold for a universal conclusion").
+reason(arg_false_dilemma, "a relevant alternative is omitted").
+
+type(?a, illegitimate_reasoning) :- fallacy(?a, ?_).
+conclusion(?a, ?c) :- fallacy(?a, ?_), concludes(?a, ?c).
+reason(?a, ?r) :- fallacy(?a, ?_), reason(?a, ?r).
+sampleSize(?a, ?n) :- fallacy(?a, hasty_generalization), sample_size(?a, ?n).
+requiredSampleSize(?a, ?min) :- fallacy(?a, hasty_generalization), required_sample_size(?a, ?min).
+omittedAlternative(?a, ?alt) :- fallacy(?a, false_dilemma), omitted_alternative(?a, ?alt).

package/examples/integer-partitions.eye

@@ -0,0 +1,35 @@
+% Integer partition counts by tabled dynamic programming.
+%
+% partitions(N, K, Count) counts unordered sums of N using parts no larger than K.
+% The two recursive branches are the standard include-K / exclude-K split.  Without
+% memoization the same (N,K) subproblems are reached many times.
+materialize(partition_answer, 2).
+
+table(partitions, 3).
+
+% One empty sum partitions zero; positive N with K=0 is impossible.
+partitions(0, ?_k, 1).
+partitions(?n, 0, 0) :- gt(?n, 0).
+partitions(?n, ?k, ?count) :-
+  gt(?n, 0),
+  gt(?k, 0),
+  gt(?k, ?n),
+  sub(?k, 1, ?k1),
+  partitions(?n, ?k1, ?count).
+partitions(?n, ?k, ?count) :-
+  gt(?n, 0),
+  gt(?k, 0),
+  le(?k, ?n),
+  sub(?n, ?k, ?remainder),
+  partitions(?remainder, ?k, ?withk),
+  sub(?k, 1, ?k1),
+  partitions(?n, ?k1, ?withoutk),
+  add(?withk, ?withoutk, ?count).
+
+% The ordinary partition number p(N) allows all parts up to N.
+partition_count(?n, ?count) :- partitions(?n, ?n, ?count).
+
+partition_answer(p_12, ?count) :- partition_count(12, ?count).
+partition_answer(p_15, ?count) :- partition_count(15, ?count).
+partition_answer(p_16_using_parts_at_most_5, ?count) :- partitions(16, 5, ?count).
+partition_answer(cumulative_p_1_to_8, ?sum) :- sumall(?c, (between(1, 8, ?n), partition_count(?n, ?c)), ?sum).

package/examples/intuitionistic-logic-kripke.eye

@@ -0,0 +1,69 @@
+% Intuitionistic logic emulation with a finite Kripke model.
+%
+% The preorder leq/2 represents information growth: later worlds contain at
+% least as much information as earlier worlds.  Atomic facts persist upward, and
+% implication is checked at every future world.  This lets the example show a
+% constructive implication that holds while excluded middle is not forced at the
+% root world.
+materialize(intuitionistic_truth, 3).
+materialize(intuitionistic_countermodel, 3).
+
+table(leq, 2).
+table(forces, 2).
+
+world(root).
+world(left).
+world(right).
+world(both).
+
+step(root, left).
+step(root, right).
+step(left, both).
+step(right, both).
+
+base(left, p).
+base(right, q).
+
+leq(?world, ?world) :- world(?world).
+leq(?from, ?to) :- step(?from, ?mid), leq(?mid, ?to).
+
+% Upward persistence for atoms: if P becomes known at SomeWorld, every later
+% world also forces P.
+forces(?world, atom(?prop)) :-
+  leq(?someworld, ?world),
+  base(?someworld, ?prop).
+
+forces(?world, and(?left, ?right)) :-
+  forces(?world, ?left),
+  forces(?world, ?right).
+
+forces(?world, or(?left, ?_right)) :- forces(?world, ?left).
+forces(?world, or(?_left, ?right)) :- forces(?world, ?right).
+
+% A -> B holds at World when no future world has A without B.
+forces(?world, implies(?left, ?right)) :-
+  world(?world),
+  not(bad_implication(?world, ?left, ?right)).
+
+forces(?world, neg(?formula)) :-
+  forces(?world, implies(?formula, bottom)).
+
+bad_implication(?world, ?left, ?right) :-
+  leq(?world, ?future),
+  forces(?future, ?left),
+  not(forces(?future, ?right)).
+
+intuitionistic_truth(monotone_p_reaches_both, both, atom(p)) :-
+  forces(both, atom(p)).
+
+intuitionistic_truth(constructive_case_analysis, root, implies(atom(p), or(atom(p), atom(q)))) :-
+  forces(root, implies(atom(p), or(atom(p), atom(q)))).
+
+intuitionistic_truth(double_negated_branch_information, root, neg(neg(or(atom(p), atom(q))))) :-
+  forces(root, neg(neg(or(atom(p), atom(q))))).
+
+intuitionistic_countermodel(root_does_not_decide_branch, root, or(atom(p), atom(q))) :-
+  not(forces(root, or(atom(p), atom(q)))).
+
+intuitionistic_countermodel(excluded_middle_not_forced, root, or(atom(p), neg(atom(p)))) :-
+  not(forces(root, or(atom(p), neg(atom(p))))).

package/examples/job-shop-scheduling.eye

@@ -0,0 +1,48 @@
+% Tiny job-shop scheduling benchmark.
+%
+% Three jobs each require one mill operation and one lathe operation, with fixed
+% within-job precedence constraints.  The solver enumerates bounded start times,
+% rejects machine overlaps, and uses aggregate_min/5 to keep the minimum makespan.
+materialize(job_shop_answer, 2).
+
+% Two operations on the same machine are compatible when either one finishes before the other starts.
+nonoverlap(?_starta, ?enda, ?startb, ?_endb) :- le(?enda, ?startb).
+nonoverlap(?starta, ?_enda, ?_startb, ?endb) :- le(?endb, ?starta).
+
+feasible_schedule(?makespan, [
+  op(j1_mill, ?j1millstart, ?j1millend),
+  op(j1_lathe, ?j1lathestart, ?j1latheend),
+  op(j2_lathe, ?j2lathestart, ?j2latheend),
+  op(j2_mill, ?j2millstart, ?j2millend),
+  op(j3_mill, ?j3millstart, ?j3millend),
+  op(j3_lathe, ?j3lathestart, ?j3latheend)
+]) :-
+  between(0, 6, ?j1millstart), add(?j1millstart, 3, ?j1millend),
+  between(0, 6, ?j1lathestart), add(?j1lathestart, 2, ?j1latheend),
+  le(?j1millend, ?j1lathestart),
+
+  between(0, 6, ?j2lathestart), add(?j2lathestart, 2, ?j2latheend),
+  between(0, 6, ?j2millstart), add(?j2millstart, 4, ?j2millend),
+  le(?j2latheend, ?j2millstart),
+
+  between(0, 6, ?j3millstart), add(?j3millstart, 2, ?j3millend),
+  between(0, 6, ?j3lathestart), add(?j3lathestart, 3, ?j3latheend),
+  le(?j3millend, ?j3lathestart),
+
+  nonoverlap(?j1millstart, ?j1millend, ?j2millstart, ?j2millend),
+  nonoverlap(?j1millstart, ?j1millend, ?j3millstart, ?j3millend),
+  nonoverlap(?j2millstart, ?j2millend, ?j3millstart, ?j3millend),
+  nonoverlap(?j1lathestart, ?j1latheend, ?j2lathestart, ?j2latheend),
+  nonoverlap(?j1lathestart, ?j1latheend, ?j3lathestart, ?j3latheend),
+  nonoverlap(?j2lathestart, ?j2latheend, ?j3lathestart, ?j3latheend),
+
+  max(?j1latheend, ?j2millend, ?partialmakespan),
+  max(?partialmakespan, ?j3latheend, ?makespan).
+
+% aggregate_min/5 returns both the best makespan and the schedule that achieved it.
+best_schedule(?makespan, ?schedule) :-
+  aggregate_min(?makespan, ?schedule, feasible_schedule(?makespan, ?schedule), ?makespan, ?schedule).
+
+job_shop_answer(best_makespan, ?makespan) :- best_schedule(?makespan, ?_schedule).
+job_shop_answer(best_schedule, ?schedule) :- best_schedule(?_makespan, ?schedule).
+job_shop_answer(feasible_schedule_count, ?count) :- countall(feasible_schedule(?_makespan, ?_schedule), ?count).

package/examples/knapsack-optimization.eye

@@ -0,0 +1,46 @@
+% 0/1 knapsack optimization with aggregate_max/5.
+%
+% subset/2 enumerates candidate expedition packs; total_weight/2 and total_value/2
+% score each pack.  feasible_pack/3 applies the capacity limit, and best_pack/3
+% keeps the highest-value feasible choice together with its weight.
+materialize(knapsack_answer, 2).
+
+% Capacity and item table are separated from the optimization rule for easy tuning.
+capacity(15).
+items([atlas, battery, camera, drone, emergency_radio, field_laptop, medkit, sensor]).
+
+item(atlas, 2, 6).
+item(battery, 4, 10).
+item(camera, 3, 8).
+item(drone, 6, 13).
+item(emergency_radio, 5, 11).
+item(field_laptop, 7, 16).
+item(medkit, 4, 9).
+item(sensor, 2, 7).
+
+% The include/exclude subset generator explores every 0/1 choice once.
+subset([], []).
+subset([?item|?rest], [?item|?chosen]) :- subset(?rest, ?chosen).
+subset([?_item|?rest], ?chosen) :- subset(?rest, ?chosen).
+
+item_weight(?item, ?weight) :- item(?item, ?weight, ?_value).
+item_value(?item, ?value) :- item(?item, ?_weight, ?value).
+
+total_weight(?items, ?weight) :- findall(?w, (member(?item, ?items), item_weight(?item, ?w)), ?weights), sum_list(?weights, ?weight).
+total_value(?items, ?value) :- findall(?v, (member(?item, ?items), item_value(?item, ?v)), ?values), sum_list(?values, ?value).
+
+feasible_pack(?pack, ?weight, ?value) :-
+  items(?all),
+  subset(?all, ?pack),
+  total_weight(?pack, ?weight),
+  capacity(?capacity),
+  le(?weight, ?capacity),
+  total_value(?pack, ?value).
+
+best_pack(?pack, ?weight, ?value) :-
+  aggregate_max(?value, pack(?pack, ?weight), feasible_pack(?pack, ?weight, ?value), ?value, pack(?pack, ?weight)).
+
+knapsack_answer(best_pack, ?pack) :- best_pack(?pack, ?_weight, ?_value).
+knapsack_answer(total_weight, ?weight) :- best_pack(?_pack, ?weight, ?_value).
+knapsack_answer(total_value, ?value) :- best_pack(?_pack, ?_weight, ?value).
+knapsack_answer(feasible_pack_count, ?count) :- countall(feasible_pack(?_pack, ?_weight, ?_value), ?count).

package/examples/knowledge-engineering-alignment-flow.eye

@@ -0,0 +1,46 @@
+% Knowledge-engineering alignment flow in Eyelang.
+%
+% The source graph uses local observation predicates.  The mapping facts below
+% align those local names with small SOSA-like and FPV-like vocabulary atoms, then
+% generic rules emit a target-shaped flow view.
+%
+% This demonstrates a common knowledge-engineering pattern: keep source data in
+% its original shape, describe the alignment declaratively, and derive target facts
+% without rewriting the original assertions.
+
+materialize(type, 2).
+materialize(target_fact, 3).
+materialize(runtime_rule, 2).
+materialize(target_predicate, 2).
+materialize(flow_emits, 2).
+materialize(trusted_by, 2).
+
+sub_class(local_observation, sosa_observation).
+sub_class(temperature_probe, sosa_sensor).
+sub_property(observed_by, sosa_madeBySensor).
+sub_property(observed_at, sosa_resultTime).
+sub_property(temperature_celsius, sosa_hasSimpleResult).
+sub_property(in_flow, fpv_hasFlowStep).
+equivalent_property(observed_feature, sosa_hasFeatureOfInterest).
+
+type(msg1, local_observation).
+type(probe7, temperature_probe).
+triple(msg1, observed_by, probe7).
+triple(msg1, observed_at, "2026-06-17T12:34:56Z").
+triple(msg1, temperature_celsius, 18.6).
+triple(msg1, observed_feature, platform_b).
+triple(msg1, in_flow, ingest_step).
+
+% Generic alignment rules.
+type(?thing, ?super) :- type(?thing, ?class), sub_class(?class, ?super).
+target_fact(?subject, ?superpredicate, ?object) :- triple(?subject, ?predicate, ?object), sub_property(?predicate, ?superpredicate).
+target_fact(?subject, ?targetpredicate, ?object) :- triple(?subject, ?predicate, ?object), equivalent_property(?predicate, ?targetpredicate).
+target_fact(?subject, ?sourcepredicate, ?object) :- triple(?subject, ?predicate, ?object), equivalent_property(?sourcepredicate, ?predicate).
+
+runtime_rule(?sourcepredicate, copy_to_target) :- sub_property(?sourcepredicate, ?_targetpredicate).
+runtime_rule(?sourcepredicate, copy_to_target) :- equivalent_property(?sourcepredicate, ?_targetpredicate).
+target_predicate(?sourcepredicate, ?targetpredicate) :- sub_property(?sourcepredicate, ?targetpredicate).
+target_predicate(?sourcepredicate, ?targetpredicate) :- equivalent_property(?sourcepredicate, ?targetpredicate).
+
+flow_emits(?step, ?message) :- type(?message, sosa_observation), target_fact(?message, fpv_hasFlowStep, ?step), target_fact(?message, sosa_madeBySensor, ?_sensor).
+trusted_by(?step, ?sensor) :- type(?message, sosa_observation), target_fact(?message, fpv_hasFlowStep, ?step), target_fact(?message, sosa_madeBySensor, ?sensor).

package/examples/law-of-cosines.eye

@@ -0,0 +1,37 @@
+% Law of cosines: c^2 = a^2 + b^2 - 2ab cos(C).
+%
+% This pure-geometry example keeps trigonometry outside the language by storing
+% cos(C) as data.  Eyelang then performs the algebraic part of the theorem with
+% ordinary arithmetic predicates and materializes both c^2 and c.
+%
+% The 60-degree sample uses cos(C) = 0.5, so the proof shows each intermediate
+% numeric step rather than hiding the computation in one builtin.
+materialize(sideCSquared, 2).
+materialize(sideC, 2).
+materialize(status, 2).
+
+% The triangle fact stores the two known sides and the cosine of the included
+% angle.  Storing cos(C) directly avoids needing trigonometric built-ins while
+% still demonstrating the geometric formula.
+triangle(tri60, 7, 9, 0.5).
+
+% Compute c^2 first so both squared and square-rooted outputs can be shown.
+% side_c_squared/2 follows the law of cosines step by step, then side_c/2
+% takes the square root for the reported side length.
+side_c_squared(?triangle, ?c2) :-
+  triangle(?triangle, ?a, ?b, ?cosc),
+  mul(?a, ?a, ?a2),
+  mul(?b, ?b, ?b2),
+  add(?a2, ?b2, ?sum),
+  mul(2, ?a, ?twoa),
+  mul(?twoa, ?b, ?twoab),
+  mul(?twoab, ?cosc, ?projection),
+  sub(?sum, ?projection, ?c2).
+
+side_c(?triangle, ?c) :-
+  side_c_squared(?triangle, ?c2),
+  pow(?c2, 0.5, ?c).
+
+sideCSquared(?triangle, ?c2) :- side_c_squared(?triangle, ?c2).
+sideC(?triangle, ?c) :- side_c(?triangle, ?c).
+status(?triangle, acute_triangle) :- side_c_squared(?triangle, ?c2), gt(?c2, 0).