eyelang 1.7.16 → 2.0.0

package/examples/braking-safety-worlds.eye

@@ -1,69 +0,0 @@
-% EYE reasoning-inspired example: braking safety in alternative worlds.
-%
-% Four simplified models classify the same road scenarios. The example is not a
-% real safety calculator; it demonstrates rule-level model comparison.
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-materialize(safeInWorld, 2).
-materialize(riskyInWorld, 2).
-materialize(status, 2).
-materialize(reason, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-scenario(city_dry, 13.9, 0.8, 40.0).
-scenario(highway_dry_short_gap, 27.8, 0.8, 60.0).
-scenario(city_wet, 13.9, 0.4, 40.0).
-scenario(city_ice, 13.9, 0.2, 30.0).
-
-world(w0, "physics-based stopping distance with reaction time").
-world(w1, "simplified braking-only rule without reaction time").
-world(w2, "naive dry-road friction assumption").
-world(w3, "cautious factor over the physics model").
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-stop_distance(?scenario, w0, ?distance) :-
-  scenario(?scenario, ?v, ?mu, ?avail),
-  mul(?v, 1.0, ?reaction),
-  pow(?v, 2.0, ?v2),
-  mul(?mu, 2.0, ?m2),
-  mul(?m2, 9.8, ?denom),
-  div(?v2, ?denom, ?braking),
-  add(?reaction, ?braking, ?distance).
-
-stop_distance(?scenario, w1, ?distance) :-
-  scenario(?scenario, ?v, ?mu, ?avail),
-  pow(?v, 2.0, ?v2),
-  mul(?mu, 2.0, ?m2),
-  mul(?m2, 10.0, ?denom),
-  div(?v2, ?denom, ?distance).
-
-stop_distance(?scenario, w2, ?distance) :-
-  scenario(?scenario, ?v, ?mu, ?avail),
-  pow(?v, 2.0, ?v2),
-  div(?v2, 14.0, ?distance).
-
-stop_distance(?scenario, w3, ?distance) :-
-  stop_distance(?scenario, w0, ?w0distance),
-  mul(?w0distance, 1.5, ?distance).
-
-safe_in_world(?scenario, ?world) :-
-  scenario(?scenario, ?v, ?mu, ?avail),
-  stop_distance(?scenario, ?world, ?distance),
-  le(?distance, ?avail).
-
-risky_in_world(?scenario, ?world) :-
-  scenario(?scenario, ?v, ?mu, ?avail),
-  stop_distance(?scenario, ?world, ?distance),
-  gt(?distance, ?avail).
-
-pattern_matches(report) :-
-  safe_in_world(city_dry, w0), safe_in_world(city_dry, w1), safe_in_world(city_dry, w2), safe_in_world(city_dry, w3),
-  risky_in_world(highway_dry_short_gap, w0), risky_in_world(highway_dry_short_gap, w3),
-  safe_in_world(highway_dry_short_gap, w1), safe_in_world(highway_dry_short_gap, w2),
-  safe_in_world(city_wet, w0), safe_in_world(city_wet, w1), safe_in_world(city_wet, w2), risky_in_world(city_wet, w3),
-  risky_in_world(city_ice, w0), risky_in_world(city_ice, w1), risky_in_world(city_ice, w3), safe_in_world(city_ice, w2).
-
-safeInWorld(?scenario, ?world) :- safe_in_world(?scenario, ?world).
-riskyInWorld(?scenario, ?world) :- risky_in_world(?scenario, ?world).
-status(braking_safety_worlds, expected_world_pattern) :- pattern_matches(report).
-reason(braking_safety_worlds, "simplified and naive worlds can be optimistic while the cautious world tightens the reference model") :- pattern_matches(report).

package/examples/buck-converter-design.eye

@@ -1,83 +0,0 @@
-% Engineering example: buck-converter ripple check.
-%
-% A simplified continuous-conduction buck converter model computes duty cycle,
-% inductor ripple current, capacitor ripple voltage, and checks design limits.
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-%
-% The constants describe one regulator design. The rules intentionally keep
-% each engineering equation separate so proof output can point to the exact
-% calculation that made the design pass or fail.
-materialize(dutyCycle, 2).
-materialize(inductorRipple_A, 2).
-materialize(rippleRatio, 2).
-materialize(capacitorRipple_V, 2).
-materialize(status, 2).
-materialize(reason, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-converter(regulator1, inputVoltage_V, 24.0).
-converter(regulator1, outputVoltage_V, 5.0).
-converter(regulator1, loadCurrent_A, 2.0).
-converter(regulator1, switchingFrequency_Hz, 500000.0).
-converter(regulator1, inductance_H, 0.000022).
-converter(regulator1, capacitance_F, 0.000047).
-limit(regulator1, maxRippleRatio, 0.30).
-limit(regulator1, maxOutputRipple_V, 0.05).
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-duty_cycle(?converter, ?duty) :-
-  converter(?converter, outputVoltage_V, ?outputvoltage),
-  converter(?converter, inputVoltage_V, ?inputvoltage),
-  div(?outputvoltage, ?inputvoltage, ?duty).
-
-inductor_ripple_current(?converter, ?ripplecurrent) :-
-  converter(?converter, inputVoltage_V, ?inputvoltage),
-  converter(?converter, outputVoltage_V, ?outputvoltage),
-  converter(?converter, inductance_H, ?inductance),
-  converter(?converter, switchingFrequency_Hz, ?frequency),
-  duty_cycle(?converter, ?duty),
-  sub(?inputvoltage, ?outputvoltage, ?voltageacrossinductor),
-  mul(?voltageacrossinductor, ?duty, ?numerator),
-  mul(?inductance, ?frequency, ?denominator),
-  div(?numerator, ?denominator, ?ripplecurrent).
-
-ripple_ratio(?converter, ?ratio) :-
-  inductor_ripple_current(?converter, ?ripplecurrent),
-  converter(?converter, loadCurrent_A, ?loadcurrent),
-  div(?ripplecurrent, ?loadcurrent, ?ratio).
-
-capacitor_ripple_voltage(?converter, ?ripplevoltage) :-
-  inductor_ripple_current(?converter, ?ripplecurrent),
-  converter(?converter, switchingFrequency_Hz, ?frequency),
-  converter(?converter, capacitance_F, ?capacitance),
-  mul(8.0, ?frequency, ?eightf),
-  mul(?eightf, ?capacitance, ?denominator),
-  div(?ripplecurrent, ?denominator, ?ripplevoltage).
-
-% within_ripple_limits/1 is the design gate for ripple current and output voltage.
-within_ripple_limits(?converter) :-
-  ripple_ratio(?converter, ?ratio),
-  limit(?converter, maxRippleRatio, ?maxratio),
-  lt(?ratio, ?maxratio),
-  capacitor_ripple_voltage(?converter, ?ripplevoltage),
-  limit(?converter, maxOutputRipple_V, ?maxripplevoltage),
-  lt(?ripplevoltage, ?maxripplevoltage).
-
-dutyCycle(?converter, ?duty) :-
-  duty_cycle(?converter, ?duty).
-
-inductorRipple_A(?converter, ?ripplecurrent) :-
-  inductor_ripple_current(?converter, ?ripplecurrent).
-
-rippleRatio(?converter, ?ratio) :-
-  ripple_ratio(?converter, ?ratio).
-
-capacitorRipple_V(?converter, ?ripplevoltage) :-
-  capacitor_ripple_voltage(?converter, ?ripplevoltage).
-
-status(?converter, stable_ripple_design) :-
-  within_ripple_limits(?converter).
-
-reason(?converter, "inductor-current and output-voltage ripple are below design limits") :-
-  within_ripple_limits(?converter).

package/examples/cache-performance.eye

@@ -1,56 +0,0 @@
-% Technology example: cache performance summary.
-%
-% A service has cache hits and misses with different response latencies. The
-% rules compute hit rate and weighted average latency, then classify whether
-% the cache is effective.
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-materialize(hitRate, 2).
-materialize(averageLatency_ms, 2).
-materialize(status, 2).
-materialize(reason, 2).
-
-% cache_sample/5 contains hits, misses, and the two latency classes; threshold/3
-% contains the operational targets used by the status rule.
-cache_sample(api_cache, 8600.0, 1400.0, 5.0, 80.0).
-threshold(api_cache, minimum_hit_rate, 0.80).
-threshold(api_cache, maximum_average_latency_ms, 20.0).
-
-% The rules compute total requests, hit rate, and weighted latency before
-% applying both acceptance thresholds together.
-total_requests(?cache, ?total) :-
-  cache_sample(?cache, ?hits, ?misses, ?_hitlatency, ?_misslatency),
-  add(?hits, ?misses, ?total).
-
-hit_rate(?cache, ?rate) :-
-  cache_sample(?cache, ?hits, ?_misses, ?_hitlatency, ?_misslatency),
-  total_requests(?cache, ?total),
-  div(?hits, ?total, ?rate).
-
-average_latency(?cache, ?average) :-
-  cache_sample(?cache, ?hits, ?misses, ?hitlatency, ?misslatency),
-  mul(?hits, ?hitlatency, ?hitcost),
-  mul(?misses, ?misslatency, ?misscost),
-  add(?hitcost, ?misscost, ?totalcost),
-  total_requests(?cache, ?total),
-  div(?totalcost, ?total, ?average).
-
-cache_effective(?cache) :-
-  hit_rate(?cache, ?rate),
-  threshold(?cache, minimum_hit_rate, ?minimumrate),
-  gt(?rate, ?minimumrate),
-  average_latency(?cache, ?average),
-  threshold(?cache, maximum_average_latency_ms, ?maximumlatency),
-  lt(?average, ?maximumlatency).
-
-hitRate(?cache, ?rate) :-
-  hit_rate(?cache, ?rate).
-
-averageLatency_ms(?cache, ?average) :-
-  average_latency(?cache, ?average).
-
-status(?cache, cache_effective) :-
-  cache_effective(?cache).
-
-reason(?cache, "hit rate is above target and average latency is below limit") :-
-  cache_effective(?cache).

package/examples/canary-release.eye

@@ -1,51 +0,0 @@
-% Technology example: canary release decision.
-%
-% A canary deployment is rolled back when its measured error rate exceeds the
-% allowed budget, even when latency is still acceptable.
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-materialize(errorRate, 2).
-materialize(p95Latency_ms, 2).
-materialize(latencyCheck, 2).
-materialize(status, 2).
-materialize(reason, 2).
-
-% canary/4 records request count, error count, and p95 latency; thresholds
-% make the rollout policy explicit data rather than constants hidden in rules.
-canary(canary42, 5000.0, 75.0, 180.0).
-threshold(canary42, maximum_error_rate, 0.01).
-threshold(canary42, maximum_p95_latency_ms, 200.0).
-
-% The latency and error-budget checks are independent so the final rollback
-% reason can point to the failing guard.
-error_rate(?release, ?rate) :-
-  canary(?release, ?requests, ?errors, ?_p95latency),
-  div(?errors, ?requests, ?rate).
-
-latency_ok(?release) :-
-  canary(?release, ?_requests, ?_errors, ?p95latency),
-  threshold(?release, maximum_p95_latency_ms, ?maximum),
-  lt(?p95latency, ?maximum).
-
-error_budget_exceeded(?release) :-
-  error_rate(?release, ?rate),
-  threshold(?release, maximum_error_rate, ?maximum),
-  gt(?rate, ?maximum).
-
-rollback_recommended(?release) :-
-  error_budget_exceeded(?release).
-
-errorRate(?release, ?rate) :-
-  error_rate(?release, ?rate).
-
-p95Latency_ms(?release, ?p95latency) :-
-  canary(?release, ?_requests, ?_errors, ?p95latency).
-
-latencyCheck(?release, ok) :-
-  latency_ok(?release).
-
-status(?release, rollback_recommended) :-
-  rollback_recommended(?release).
-
-reason(?release, "canary error rate exceeds the allowed budget") :-
-  rollback_recommended(?release).

package/examples/cat-koko.eye

@@ -1,24 +0,0 @@
-% Cat Koko, adapted from Eyeling's examples/cat-koko.n3.
-%
-% The Eyeling output contains two existential witnesses. eyelang has no blank
-% node constructor in the portable core, so this adaptation names those
-% witnesses sk_0 and sk_1.
-
-% 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.
-animal(koko).
-
-witness(cat, sk_0).
-witness(british_short_hair, sk_1).
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-type(?x, cat) :- animal(koko), witness(cat, ?x).
-type(?x, british_short_hair) :- animal(koko), witness(british_short_hair, ?x).
-
-is(test, true) :-
-  type(?x, cat),
-  type(?y, british_short_hair),
-  neq(?x, ?y).

package/examples/catalan-convolution.eye

@@ -1,37 +0,0 @@
-% Catalan numbers by tabled convolution.
-%
-% catalan(N,C) sums all splits of N-1 into left and right substructures.  The same
-% Catalan values appear in binary tree shapes, parenthesizations, and polygon
-% triangulations, shown here with small wrapper predicates.
-materialize(catalan_answer, 2).
-
-table(catalan, 2).
-
-% C_0 = 1; higher values are computed by the convolution sum.
-catalan(0, 1).
-catalan(?n, ?c) :-
-  gt(?n, 0),
-  sub(?n, 1, ?n1),
-  sumall(?product,
-    (between(0, ?n1, ?i),
-     sub(?n1, ?i, ?j),
-     catalan(?i, ?a),
-     catalan(?j, ?b),
-     mul(?a, ?b, ?product)),
-    ?c).
-
-% An n-gon has C_(n-2) triangulations.
-polygon_triangulations(?sides, ?count) :-
-  ge(?sides, 3),
-  sub(?sides, 2, ?n),
-  catalan(?n, ?count).
-
-parenthesizations(?factors, ?count) :-
-  ge(?factors, 1),
-  sub(?factors, 1, ?n),
-  catalan(?n, ?count).
-
-catalan_answer(catalan_12, ?c) :- catalan(12, ?c).
-catalan_answer(triangulations_14_gon, ?count) :- polygon_triangulations(14, ?count).
-catalan_answer(parenthesizations_13_factors, ?count) :- parenthesizations(13, ?count).
-catalan_answer(first_ten_sum, ?sum) :- sumall(?c, (between(0, 9, ?n), catalan(?n, ?c)), ?sum).

package/examples/cdcl-sat-solver.eye

@@ -1,65 +0,0 @@
-% A tiny CDCL-style SAT trace with one learned clause.
-%
-% Industrial CDCL solvers use watched literals, mutable trails, non-chronological
-% backjumping, clause databases, restarts, and activity heuristics.  Eyelang has
-% no mutable state or destructive trail updates, so this example models one small
-% conflict-analysis episode as relations over immutable terms.
-%
-% Formula:
-%   c1: not(a) or c
-%   c2: not(c)
-%   c3: a or b
-%
-% Decision a=true forces c=true by c1, which conflicts with c2.  Resolving the
-% reason c1 with the conflict c2 learns not(a).  After backjumping, learned
-% not(a) forces a=false, c2 gives c=false, and c3 forces b=true.
-
-materialize(cdclAnswer, 2).
-
-clause(c1, [neg(a), pos(c)]).
-clause(c2, [neg(c)]).
-clause(c3, [pos(a), pos(b)]).
-
-% Initial trail before conflict analysis.
-initial_value(a, true, decision(level1)).
-initial_value(c, true, implied_by(c1)).
-
-% The current trail makes a literal true or false.
-lit_true(pos(?var), ?value_rel) :- call_value(?value_rel, ?var, true, ?).
-lit_true(neg(?var), ?value_rel) :- call_value(?value_rel, ?var, false, ?).
-lit_false(pos(?var), ?value_rel) :- call_value(?value_rel, ?var, false, ?).
-lit_false(neg(?var), ?value_rel) :- call_value(?value_rel, ?var, true, ?).
-
-% Eyelang cannot pass predicates as first-class values, so this small dispatcher
-% lets the same literal helpers inspect either the initial or final trail.
-call_value(initial, ?var, ?value, ?reason) :- initial_value(?var, ?value, ?reason).
-call_value(final, ?var, ?value, ?reason) :- final_value(?var, ?value, ?reason).
-
-% A clause is conflicting when all of its literals are false under a trail.
-conflict(?trail, ?clause) :-
-  clause(?clause, ?literals),
-  forall(member(?literal, ?literals), lit_false(?literal, ?trail)).
-
-% The learned clause for this tiny implication graph is obtained by resolving
-% the conflict clause not(c) with c's reason not(a) or c, yielding not(a).
-learned_clause(l1, [neg(a)]).
-learned_from(l1, resolve(c2, c1, pivot(c))).
-
-% After backjumping, the learned unit clause fixes a=false.  Then the original
-% clauses imply c=false and b=true.
-final_value(a, false, learned(l1)).
-final_value(c, false, unit(c2)).
-final_value(b, true, unit(c3)).
-
-model_satisfies_clause(?trail, ?clause) :-
-  clause(?clause, ?literals),
-  member(?literal, ?literals),
-  lit_true(?literal, ?trail).
-
-final_model_ok(ok) :- forall(clause(?name, ?), model_satisfies_clause(final, ?name)).
-
-cdclAnswer(conflict_clause, ?clause) :- conflict(initial, ?clause).
-cdclAnswer(learned_clause, ?literals) :- learned_clause(l1, ?literals).
-cdclAnswer(learned_from, ?reason) :- learned_from(l1, ?reason).
-cdclAnswer(final_value(?var), ?value) :- final_model_ok(ok), final_value(?var, ?value, ?).
-cdclAnswer(note, "one learned clause makes the final model satisfy all original clauses") :- final_model_ok(ok).

package/examples/chart-parser.eye

@@ -1,65 +0,0 @@
-% A tiny tabled chart parser for a context-free grammar.
-%
-% span(Sentence, Category, Start, End) is the dynamic-programming chart item:
-% Category covers a half-open token interval.  Memoizing span/4 turns recursive
-% grammar recognition into chart parsing, so ambiguous phrases share subparses.
-materialize(chart_parser_answer, 2).
-
-table(span, 4).
-
-% Two sample sentences share the same tiny grammar but have different parse counts.
-
-sentence(command, 5).
-sentence(ambiguous_pp, 8).
-
-word(command, 0, the).
-word(command, 1, robot).
-word(command, 2, moves).
-word(command, 3, the).
-word(command, 4, box).
-
-word(ambiguous_pp, 0, the).
-word(ambiguous_pp, 1, robot).
-word(ambiguous_pp, 2, sees).
-word(ambiguous_pp, 3, the).
-word(ambiguous_pp, 4, box).
-word(ambiguous_pp, 5, with).
-word(ambiguous_pp, 6, the).
-word(ambiguous_pp, 7, telescope).
-
-terminal(det, the).
-terminal(noun, robot).
-terminal(noun, box).
-terminal(noun, telescope).
-terminal(verb, moves).
-terminal(verb, sees).
-terminal(prep, with).
-
-rule(s, np, vp).
-rule(np, det, noun).
-rule(np, np, pp).
-rule(vp, verb, np).
-rule(vp, vp, pp).
-rule(pp, prep, np).
-
-% Lexical chart items come directly from words and terminal categories.
-span(?sentence, ?category, ?start, ?end) :-
-  word(?sentence, ?start, ?token),
-  terminal(?category, ?token),
-  add(?start, 1, ?end).
-% Nonterminal chart items split the interval at a Middle point.
-span(?sentence, ?category, ?start, ?end) :-
-  rule(?category, ?left, ?right),
-  span(?sentence, ?left, ?start, ?middle),
-  span(?sentence, ?right, ?middle, ?end).
-
-chart_parser_answer(parsed, ?sentence) :-
-  sentence(?sentence, ?length),
-  span(?sentence, s, 0, ?length).
-chart_parser_answer(parse_count, count(?sentence, ?count)) :-
-  sentence(?sentence, ?length),
-  countall(span(?sentence, s, 0, ?length), ?count).
-chart_parser_answer(noun_phrase_count, count(?sentence, ?count)) :-
-  sentence(?sentence, ?length),
-  countall(span(?sentence, np, ?_start, ?_end), ?count),
-  gt(?length, 0).

package/examples/clinical-trial-screening.eye

@@ -1,97 +0,0 @@
-% Representative example: clinical-trial screening.
-%
-% The program models a small diabetes trial screening workflow. Helper
-% predicates keep the inclusion/exclusion logic separate from the concise
-% public relation report.
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-%
-% Inclusion criteria are positive requirements; exclusion criteria veto a
-% candidate even when the inclusion checks pass. The emitted reason/2 facts are
-% the audit trail a coordinator would need for a screen-failure report.
-materialize(type, 2).
-materialize(status, 2).
-materialize(reason, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-patient(p001).
-patient(p002).
-patient(p003).
-patient(p004).
-
-age(p001, 54).
-age(p002, 67).
-age(p003, 31).
-age(p004, 45).
-
-diagnosis(p001, type2_diabetes).
-diagnosis(p002, type2_diabetes).
-diagnosis(p003, type2_diabetes).
-diagnosis(p004, type2_diabetes).
-
-lab(p001, hba1c_pct, 8.4).
-lab(p002, hba1c_pct, 7.9).
-lab(p003, hba1c_pct, 9.1).
-lab(p004, hba1c_pct, 6.4).
-
-lab(p001, egfr_ml_min, 83.0).
-lab(p002, egfr_ml_min, 38.0).
-lab(p003, egfr_ml_min, 91.0).
-lab(p004, egfr_ml_min, 72.0).
-
-condition(p003, pregnant).
-
-% Derivation rules: each rule below contributes one logical step toward the displayed results.
-inclusion_adult(?patient) :-
-  patient(?patient),
-  age(?patient, ?age),
-  ge(?age, 18).
-
-inclusion_diagnosis(?patient) :-
-  diagnosis(?patient, type2_diabetes).
-
-inclusion_hba1c(?patient) :-
-  lab(?patient, hba1c_pct, ?hba1c),
-  ge(?hba1c, 7.0),
-  le(?hba1c, 10.5).
-
-exclusion_renal(?patient) :-
-  lab(?patient, egfr_ml_min, ?egfr),
-  lt(?egfr, 45.0).
-
-exclusion_pregnancy(?patient) :-
-  condition(?patient, pregnant).
-
-% A patient is eligible only when all inclusion checks pass and no exclusion is proven.
-screen_eligible(?patient) :-
-  inclusion_adult(?patient),
-  inclusion_diagnosis(?patient),
-  inclusion_hba1c(?patient),
-  not(exclusion_renal(?patient)),
-  not(exclusion_pregnancy(?patient)).
-
-screen_fail(?patient) :- exclusion_renal(?patient).
-screen_fail(?patient) :- exclusion_pregnancy(?patient).
-screen_fail(?patient) :- patient(?patient), not(inclusion_hba1c(?patient)).
-
-type(?patient, trial_candidate) :-
-  screen_eligible(?patient).
-
-status(?patient, eligible) :-
-  screen_eligible(?patient).
-
-reason(?patient, "meets inclusion criteria and no listed exclusion") :-
-  screen_eligible(?patient).
-
-status(?patient, screen_fail) :-
-  screen_fail(?patient).
-
-reason(?patient, "eGFR below renal safety threshold") :-
-  exclusion_renal(?patient).
-
-reason(?patient, "pregnancy exclusion applies") :-
-  exclusion_pregnancy(?patient).
-
-reason(?patient, "HbA1c is outside protocol range") :-
-  patient(?patient),
-  not(inclusion_hba1c(?patient)).

package/examples/collatz-1000.eye

@@ -1,45 +0,0 @@
-% Collatz conjecture suite translated from Eyeling's examples/collatz-1000.n3.
-% It enumerates starts N = 1000, 999, ..., 1 by deriving N = 1000 - N0
-% from a repeat relation, then materializes each full trajectory.
-%
-% Source N3:
-% https://raw.githubusercontent.com/eyereasoner/eyeling/refs/heads/main/examples/collatz-1000.n3
-
-% Output declarations: materialize/2 selects the relations written to this example's golden output.
-% table/2 caches shared suffix trajectories so the 1000 starts do not recompute
-% the same Collatz tails hundreds of times.
-materialize(collatzTrajectory, 2).
-table(collatz, 2).
-
-% Program structure: facts set up the scenario, and rules derive the materialized conclusions.
-% The N3 source defines repeat/2 recursively; this Eyelang version uses the
-% equivalent bounded generator so the 1000-case regression remains stack-safe.
-
-% Query / materialization of the test suite.
-% Generate N in {1000..1} and ask the backward-defined collatz/2 predicate
-% for the full trajectory list M.
-collatzTrajectory(?n, ?m) :-
-  repeat(1000, ?n0),
-  sub(1000, ?n0, ?n),
-  collatz(?n, ?m).
-
-% Range generator.
-% repeat(N, I) enumerates all integers I in the half-open interval [0..N-1].
-repeat(?n, ?i) :-
-  sub(?n, 1, ?last),
-  between(0, ?last, ?i).
-
-% Backward Collatz relation.
-% collatz(N, M) relates a start value N to its full trajectory list M.
-collatz(1, [1]).
-collatz(?n, [?n|?j]) :-
-  gt(?n, 1),
-  mod(?n, 2, 0),
-  div(?n, 2, ?n1),
-  collatz(?n1, ?j).
-collatz(?n, [?n|?j]) :-
-  gt(?n, 1),
-  mod(?n, 2, 1),
-  mul(3, ?n, ?t),
-  add(?t, 1, ?n1),
-  collatz(?n1, ?j).

package/examples/combinatorics-findall-sort.eye

@@ -1,38 +0,0 @@
-% Eyelet-inspired combinations example using findall/3 and sort/2.
-%
-% combination/3 generates the same subset in several selection orders.  findall/3
-% collects those candidates, and sort/2 canonicalizes the list so each unordered
-% 3-combination of five items is reported once.
-materialize(combinations, 2).
-materialize(count, 2).
-materialize(reason, 2).
-
-% select/3 nondeterministically removes one item from a list; because it is an
-% ordinary rule, the example also demonstrates user-level list recursion.
-select(?item, [?item | ?rest], ?rest).
-% The recursive clause keeps the non-selected head and searches the tail.
-select(?item, [?head | ?tail], [?head | ?rest]) :-
-  select(?item, ?tail, ?rest).
-
-% combination/3 builds an unordered K-combination by repeated selection.
-combination(0, ?_items, []).
-combination(?i, ?items, ?combination) :-
-  gt(?i, 0),
-  select(?item, ?items, ?remaining),
-  sub(?i, 1, ?j),
-  combination(?j, ?remaining, ?partial),
-  sort([?item | ?partial], ?combination).
-
-% findall collects all generation orders; sort canonicalizes and deduplicates.
-unique_combinations(?k, ?items, ?unique) :-
-  findall(?c, combination(?k, ?items, ?c), ?all),
-  sort(?all, ?unique).
-
-combinations(combinations_5_choose_3, ?unique) :-
-  unique_combinations(3, [1, 2, 3, 4, 5], ?unique).
-
-count(combinations_5_choose_3, ?count) :-
-  unique_combinations(3, [1, 2, 3, 4, 5], ?unique),
-  length(?unique, ?count).
-
-reason(combinations_5_choose_3, "findall gathers generated combinations and sort removes duplicates").