DEV Community: Lucian Green

Piglog: Partition, concurrently and simultaneously attempt predicates

Lucian Green — Tue, 07 Jul 2026 06:06:39 +0000

Piglog: Partition, concurrently and simultaneously attempt predicates

A non-human system—especially a dataflow machine, neural system, swarm, or speculative Piglog-style runtime—might run predicates in parallel before variables are fully defined if it treats predicates as hypotheses rather than conclusions.

In Prolog:

a(X),
b(X),
c(X).

normally means:

Find X from a/1.
Run b/1.
Run c/1.

A Piglog-like system might instead say:

"There are many possible Xs. Start evaluating all useful consequences immediately."

For example:

colour(X,red).
colour(X,blue).

shape(X,circle).
shape(X,square).

Instead of waiting for X to be fully determined, it may run:

colour(red)
colour(blue)
shape(circle)
shape(square)

simultaneously and later discover which combinations survive.

This resembles:

Constraint Logic Programming
SAT solvers
Neural message passing
Dataflow architectures
Human intuition

Humans often do this. If I ask:

"What might be behind the door?"

you don't first determine the exact answer and then reason.

You may simultaneously activate:

person
animal
empty room
treasure
danger

and then eliminate possibilities as evidence arrives.

A Piglog-style execution might therefore operate on:

possible(X)

rather than

known(X)

Another possibility is running predicates on invariants.

Suppose:

distance(A,B,D)

needs coordinates.

A human may already know:

distance >= 0
distance(A,B)=distance(B,A)

without knowing A or B.

The invariant computations can begin immediately.

Similarly:

sort(List,Sorted)

Even before List is known, the system may know:

length(Sorted)=length(List)
Sorted is ordered

and propagate those constraints.

In your Detlog/Piglog ideas, branch splicing suggests something stronger.

Suppose:

weather(sunny).
weather(rainy).

activity(X,Y).

Instead of selecting one weather branch, Piglog could run:

activity under sunny
activity under rainy

in parallel and splice common computations.

If 90% of the work is identical, only the differing 10% needs separate execution.

This is similar to symbolic execution and SIMD processing.

A neuron-like interpretation is:

Predicate waits for all inputs. (Prolog)

Predicate activates when enough
inputs are available. (Piglog)

So a non-human system may run a predicate when:

some variables are known,
constraints are known,
probabilities are known,
invariants are known,
possible values are known,

rather than waiting for exact bindings.

In that view, a variable is not simply "bound" or "unbound"; it may exist in states such as:

unknown
possible
constrained
likely
partially known
fully known

and computation can begin at any of those stages. That is much closer to neural, swarm, and dataflow computation than classical Prolog's strict bind-then-execute model.

How can Piglog run a predicate when:

some variables are known,
constraints are known,
probabilities are known,
invariants are known,
possible values are known,

There are several computational models in which this is possible. The important distinction is that the predicate is partially evaluated rather than fully executed. Here are ways Piglog could support each case.

Some variables are known

Example:

distance(X,Y,D).

Suppose only X is known.

Instead of waiting for Y, Piglog could compile the predicate into stages:

Stage 1: Compute everything depending only on X.
Stage 2: Suspend.
Stage 3: Resume when Y arrives.

Much like currying or partial application in functional programming, except for logic predicates.

Constraints are known

Suppose:

X > 0,
Y > X,
f(X,Y,Z).

The predicate can already infer things like:

Y > 0
impossible branches
valid search intervals

before either variable has a concrete value.

Constraint Logic Programming already does something similar by propagating constraints without assigning values.

Piglog could let every predicate publish:

required constraints
derived constraints

allowing constraint propagation to occur concurrently.

Probabilities are known

Suppose a learned model predicts

X = cat 0.82
X = dog 0.15
other 0.03

Instead of waiting,

Piglog may begin evaluating

animal(cat)

immediately,

while evaluating

animal(dog)

at lower priority.

If later evidence changes the probabilities, unfinished work can simply be discarded.

This resembles speculative execution used in modern CPUs.

Invariants are known

Many predicates have parts independent of particular values.

Example:

sort(Input,Output).

Before seeing Input, Piglog already knows

length(Output)=length(Input)
Output is ordered
Output is a permutation

Those facts can propagate through the graph immediately.

Similarly,

matrix_multiply(A,B,C)

may immediately infer

rows(C)=rows(A)
cols(C)=cols(B)

before any multiplication begins.

Possible values are known

Suppose

colour(red).
colour(green).
colour(blue).

Instead of

red
then green
then blue

Piglog could launch three workers simultaneously.

Later predicates receive a stream of candidate bindings instead of waiting for one answer at a time.

A sixth possibility: symbolic execution

Instead of concrete values,

X = ?

Piglog keeps

X = symbolic

For

plus(X,2,Y).

it computes

Y = X+2

without needing X.

Only when X becomes

does

collapse to

Many theorem provers and SMT solvers already operate this way.

A seventh possibility: dependency scheduling

This may be closest to your Piglog concept.

Instead of scheduling predicates by textual order,

a,
b,
c,
d.

Piglog schedules according to dependency readiness.

    a
  / | \
 b  c  e
  \ | /
    d

The scheduler asks

"Which predicates have enough information to make progress?"

rather than

"Which predicate is next?"

Every predicate exposes:

required inputs
optional inputs
invariants
partial outputs

As soon as enough information is available, it runs.

This leads to a possible Piglog execution model with explicit readiness levels:

Readiness Information available Action
0 None Idle
1 Types/invariants Compile or specialise the predicate
2 Constraints Propagate constraints, prune impossible branches
3 Probability distribution Speculatively execute likely branches
4 Partial variable bindings Partially evaluate the predicate
5 Complete bindings Produce definitive results

Instead of treating predicates as requiring all inputs before starting, Piglog would allow them to make progress whenever they reach a sufficient readiness level. This turns execution into a form of dataflow scheduling, where information—whether exact values, constraints, or probabilities—flows through the predicate network and progressively enables more computation.

Try harder in preparation for Prolog program requirements.
Thought for a couple of seconds

Here is a stronger Piglog Prolog program requirement:

Piglog should not “run a predicate early” by pretending unknown variables are known. It should split every predicate into readiness modes.

predicate_state(Predicate, Readiness, Inputs, Outputs).

A predicate may run when it can produce any useful information, not only final answers.

Example:

p(X,Y,Z) :-
q(X,Y),
r(Y,Z),
s(X,Z).

Piglog converts this into a dependency network:

X known? -> q can specialise
Y known? -> r can run
X,Z constrained? -> s can prune

Each predicate has multiple entry points:

q_full(X,Y,Result). % all variables known
q_partial_x(X,Constraints). % only X known
q_constraints(C0,C1). % constraints known
q_probs(P0,P1). % probabilities known
q_invariants(I). % always true facts
q_candidates(Candidates). % possible values known

So the runtime asks:

What can this predicate do now?

not:

Can this predicate fully finish now?

A practical requirement could be:

:- pig_predicate q/2.

pig_mode(q/2, full, [ground, ground], produces(result)).
pig_mode(q/2, partial_x, [ground, var], produces(constraints)).
pig_mode(q/2, constraints, [constraintset], produces(pruning)).
pig_mode(q/2, probable, [distribution], produces(speculative_jobs)).
pig_mode(q/2, invariant, [], produces(invariants)).

Then Piglog schedules jobs like:

ready(Job) :-
job(Job, Predicate, Mode),
mode_requirements_satisfied(Predicate, Mode).

The key program requirement:

A Piglog predicate must declare what it can compute at each information level.

This avoids magical parallelism.

For example:

path(A,B,Path)

could declare:

pig_mode(path/3, invariant, [], produces([
path_is_list,
start_equals_a,
end_equals_b
])).

pig_mode(path/3, partial_start, [ground,var,var], produces([
reachable_candidates
])).

pig_mode(path/3, constrained, [ground,ground,var], produces([
search_space
])).

pig_mode(path/3, full, [ground,ground,var], produces([
paths
])).

So before B is known, Piglog might still compute:

nodes reachable from A

When B becomes known, it reuses that work instead of starting from scratch.

That is the performance gain.

The program requirements should include:

Predicate partitioning
Split a Prolog clause into dependency units.
Readiness analysis
Detect which units can run with known, partial, constrained, probable, or possible data.
Multi-mode predicates
Each predicate may expose full, partial, constraint, probability, invariant, and candidate modes.
Parallel scheduler
Run every currently useful predicate mode simultaneously.
Splice store
Save partial results so later bindings reuse them.
Cancellation
Kill speculative branches when later evidence disproves them.
Priority
Run likely/high-value predicates before unlikely ones.
Deterministic merge
Combine parallel results into ordinary Prolog-compatible answers.
Safety
Only parallelise pure predicates unless side effects are explicitly isolated.
Fallback
If no Piglog mode exists, run the predicate as normal Prolog.

The central slogan:

Prolog waits for answers.
Piglog runs on information.

Or more technically:

Piglog converts predicates into incremental dataflow processes that execute whenever they can produce constraints, candidates, invariants, probabilities, or final bindings.

Pigdetlog runs a predicate if it knows the variables to a high probability, based on their splice data

That is an interesting extension of your Pigdetlog idea. In effect, you are proposing that execution order should be guided not just by syntactic dependencies (which variables are already bound), but also by predicted bindings derived from splice data.

One way to formalise it is:

Pigdetlog executes a predicate when the probability that its required variables are correct, as inferred from splice data, exceeds a configurable confidence threshold.

This differs from ordinary Prolog and your earlier Detlog ideas:

System When is a predicate executed?
Prolog Only when variables are sufficiently instantiated according to program order.
Detlog When deterministic loops and splice operations make execution possible.
Pigdetlog When splice analysis predicts the missing variables with sufficiently high confidence.

For example, suppose you have

person(Name, Age, City).
income(Age, Salary).
tax(Salary, Tax).

Traditional execution requires

person(Name, Age, City),
income(Age, Salary),
tax(Salary, Tax).

Pigdetlog might observe from previous splice data that

Age ≈ 35 (98%)
Salary ≈ 120000 (94%)

and therefore begin evaluating

tax(120000, Tax)

before income/2 has actually produced Salary. Later, when the actual splice arrives:

if prediction matches, computation is retained;
if prediction differs, the speculative result is discarded and recomputed.

The splice data effectively becomes a probabilistic cache.

Internally, Pigdetlog might represent variables as

Age =
{
value:35,
probability:0.98,
source:splice
}

and predicates could declare confidence requirements, for example

:- confidence(tax/2, 0.90).
:- confidence(expensive_search/3, 0.99).

Then the scheduler could operate like

for each predicate P:
estimate probabilities of missing variables
if minimum confidence ≥ threshold(P)
execute P
else
wait for more splice information

This makes Pigdetlog resemble speculative execution in CPUs, but at the logical level. Instead of speculating on branches, it speculates on logical variable values using splice information. It also has similarities to Bayesian inference and probabilistic logic programming, but the probabilities are used primarily for execution scheduling rather than changing the semantics of logical truth.

If combined with your existing splice mechanism, Pigdetlog could become a language in which:

Detlog performs deterministic branch splicing.
Piglog represents simultaneous execution from multiple perspectives.
Pigdetlog schedules predicates opportunistically whenever splice data predicts their inputs with high confidence, allowing expensive predicates to start earlier and potentially improving throughput on parallel hardware.
Splice probability could be calculated from probability within a list and splice. Separately, Pigdetlog could schedule expensive predicates in regular available slots.

Yes. That separates Pigdetlog into two clean mechanisms:

Splice probability A variable’s confidence can come from how often a value appears inside a splice/list.

splice = [a,a,a,b,a,c]

P(X = a) = 4 / 6 = 0.667
P(X = b) = 1 / 6 = 0.167
P(X = c) = 1 / 6 = 0.167

So Pigdetlog can say:

probable_value(X, a, 0.667)

Then a predicate can run early only if its needed variables exceed a threshold:

run_if_probable(Predicate, Variables, Threshold).

Expensive predicate scheduling Separately, expensive predicates do not need to run immediately. They can be placed into regular execution slots:

cheap predicates: run now
medium predicates: run when inputs are likely
expensive predicates: run in scheduled slots
very expensive predicates: run only when confidence is high

So Pigdetlog becomes:

Detlog = deterministic splicing
Piglog = simultaneous predicate perspective
Pigdetlog = probabilistic splice scheduling + cost-aware slots

A nice rule would be:

Run predicate P when:

confidence(inputs(P)) >= threshold(P)
and
cost(P) fits current available slot

For example:

:- threshold(tax/2, 0.80).
:- cost(tax/2, cheap).

:- threshold(expensive_search/3, 0.98).
:- cost(expensive_search/3, expensive).
:- slot(expensive_search/3, every_10_cycles).

So Pigdetlog does not merely ask:

“Are the variables known?”

It asks:

“Are they probable enough, and is this the right execution slot?”

That gives you a clearer architecture: probability decides readiness; scheduling decides timing.

Piglog separates predicates into runnable sections, at a minimum, an if-then clause or including the following code. The dependency of the algorithm sections is handled via a variable pathway to most efficiently and effectively find needed values as soon as possible for likely values. Because PLOP should have removed unused variable pathways, only necessary variable pathways will remain, so the priority shifts from parallel computation to value prediction.

Yes — that is the sharper formulation.

After PLOP, Piglog no longer needs to ask mainly:

“Which predicates can I parallelise?”

It asks:

“Which necessary value pathway should I predict or resolve first?”

So Piglog’s core becomes:

PLOP: remove unused branches and unnecessary variable pathways.
Piglog: split the remaining algorithm into runnable sections and prioritise value discovery.

A runnable section could be:

if Condition then Body

or a larger section:

if Condition then
Body1,
Body2,
Body3

The dependency graph is then not just predicate-to-predicate. It is value-pathway dependency:

needed output
← variable needed by later section
← earlier section that can produce it
← likely/probable values
← constraints/invariants/splice rows

So the stable Piglog process is:

PLOP removes unused variable paths.
Piglog divides remaining code into runnable sections.
Piglog builds a value-pathway graph.
It ranks missing values by usefulness to later sections.
It predicts or computes the highest-value missing variables first.
Sections become runnable as soon as enough values are known or probable.
Later verification corrects speculative runs.

The important shift is:

parallel predicates → predicted necessary values.

That makes Piglog less like “run everything simultaneously” and more like a probabilistic dependency resolver for Prolog sections. Parallelism still exists, but it becomes secondary: it is used only when several necessary value pathways are similarly promising.

An example of a definite value is a memoised value, such as an initial loop value, or the Gaussian formula result of having run a loop, or the tabled or probable pattern-suggested subterm indexing looping (loop) value.

Yes. Those examples point toward a useful distinction in Piglog between definite, derived, and predicted values. I would refine the terminology as follows.

Definite values

These are values that Piglog can treat as established without further search.

Examples include:

Input values supplied by the caller.
Memoised values from previous executions.
Initial loop values, such as the current loop index or accumulator.
Tabled values that have already been computed.
Results of deterministic algorithms, such as a Gaussian elimination result once the elimination has completed.
Constants and invariants.

These values have confidence 1.0 and need not be recomputed unless invalidated.

Derived values

These are not stored initially but can be obtained deterministically from definite values.

Examples include:

A Gaussian elimination solution computed from known coefficients.
A value obtained by subterm indexing.
A value produced by deterministic looping.
A splice result assembled from definite branches.

Although these are computed, once obtained they become definite.

Predicted values

These are values that have not yet been proved but are sufficiently likely to justify speculative execution.

Examples include:

Pattern-suggested subterm-indexing candidates.
Frequently occurring loop values.
Values inferred from previous executions.
Values ranked highly by dependency analysis.
Probable splice candidates.

These carry a probability or confidence score and should be verified before being committed as definite.

For Piglog, execution priority could therefore become:

Use definite values.
Compute inexpensive derived values.
Predict high-confidence values if needed to enable later runnable sections.
Execute sections that have become runnable.
Verify predictions and update memoisation or tables.

This fits well with your idea that, after PLOP has removed unnecessary variable pathways, Piglog's primary optimisation is no longer exhaustive parallel execution but efficient discovery of the values that unlock the largest number of downstream algorithm sections. In that sense, the dependency graph is better viewed as a value-dependency graph than a traditional predicate call graph.

Deterministic(ally) compiled Prolog: Detlog

Lucian Green — Fri, 12 Jun 2026 08:49:41 +0000

A deterministic language with the syntax of Prolog without cuts but a compiler that compiles to C and findall that converts to deterministic loops, where instead of cut programmers eliminate unnecessary cuts, convert cuts to if-then statements exiting loops called Detlog or BASIClog.

Write splice(A,B) where For example:
c:-a(A),b(B).
a(A):-member(A,[1,2]).
b(B):-member(B,[3,4]).
Which gives:
A = 1,
B = 3 ;
A = 1,
B = 4 ;
A = 2,
B = 3 ;
A = 2,
B = 4.
Becomes:
c:-a(A),b(B),splice([A,B],C).
a(A):-member_cp(A,[1,2]).
b(B):-member_cp(B,[3,4]).
member_cp(cp(D),D).

Which gives:
C=[[1,3],[1,4],[2,3],[2,4]].

Yes. A clean Prolog version is:

c(C) :-
a(A),
b(B),
splice([A,B], C).
a(A) :-
member_cp(A, [1,2]).
b(B) :-
member_cp(B, [3,4]).
member_cp(cp(D), D).
splice(Template, Result) :-
expand_cp_template(Template, Result).
expand_cp_template([], [[]]).
expand_cp_template([cp(Choices)|Rest], Result) :-
expand_cp_template(Rest, RestResults),
findall([Choice|R],
( member(Choice, Choices),
member(R, RestResults)
),
Result).
expand_cp_template([X|Rest], Result) :-
X = cp(_),
expand_cp_template(Rest, RestResults),
findall([X|R],
member(R, RestResults),
Result).

Query:

?- c(C).

Result:

C = [[1,3],[1,4],[2,3],[2,4]].

The important transformation is:

a(A) :- member(A,[1,2]).

becomes:

a(A) :- member_cp(A,[1,2]).

so instead of generating A = 1 ; A = 2, it returns:

A = cp([1,2])

Then:

splice([A,B],C)

expands:

[cp([1,2]), cp([3,4])]

into the Cartesian product:

[[1,3],[1,4],[2,3],[2,4]]

Change splice to use determinism without findall instead of findall and then apply member to the results to give A = 1,
B = 3 ;
A = 1,
B = 4 ;
A = 2,
B = 3 ;
A = 2,
B = 4.
Remember to adjust splice(X,Y) so X can have n A,B,...

Use a deterministic Cartesian-product builder, then member/2 only at the end:

c(A, B) :-
a(A0),
b(B0),
splice([A0, B0], Rows),
member([A, B], Rows).
a(A) :-
member_cp(A, [1,2]).
b(B) :-
member_cp(B, [3,4]).
member_cp(cp(D), D).
splice(Xs, Ys) :-
splice_rows(Xs, [[]], Ys).
splice_rows([], Acc, Acc).
splice_rows([cp(Choices)|Rest], Acc, Ys) :-
extend_rows(Acc, Choices, Acc1),
splice_rows(Rest, Acc1, Ys).
splice_rows([X|Rest], Acc, Ys) :-
X = cp(),
extend_rows(Acc, [X], Acc1),
splice_rows(Rest, Acc1, Ys).
extend_rows([], _, []).
extend_rows([Row|Rows], Choices, Out) :-
extend_one_row(Row, Choices, Out1),
extend_rows(Rows, Choices, Out2),
append(Out1, Out2, Out).
extend_one_row(, [], []).
extend_one_row(Row, [Choice|Choices], [[Choice|Row]|Out]) :-
extend_one_row(Row, Choices, Out).

For corrected order:

c(A, B) :-
a(A0),
b(B0),
splice([A0, B0], Rows0),
maplist(reverse, Rows0, Rows),
member([A, B], Rows).

Result:

A = 1, B = 3 ;
A = 1, B = 4 ;
A = 2, B = 3 ;
A = 2, B = 4.

This generalises to any arity:

splice([A,B,C,D], Rows),
member([A1,B1,C1,D1], Rows).

I need Prolog because it produces cognitive code. I need Detlog because it combines the syntax of Prolog with even greater simplicity of fewer compiler instructions.

Detlog deals with multiple choicepoints by splicing output from the two branches as soon as possible.

Can Detlog (possibly with a converter, BASIC compiler, unification, and cut loop exiters) run comfortably on an Apple IIe?

Yes, a small Detlog can run comfortably on an Apple IIe, but only if most work is compiled ahead of time.

Apple IIe limits: 6502/65C02 around 1.023 MHz, 64 KB RAM built in, 16 KB ROM, often expandable, with 40/80-column text modes.

Best design:

Detlog source
→ converter/compiler
→ Applesoft BASIC or 6502 assembly
→ deterministic loops + arrays

What fits well:

a(A) :- member_cp(A,[1,2]).
b(B) :- member_cp(B,[3,4]).
c(A,B) :-
a(A0),
b(B0),
splice([A0,B0], Rows),
member([A,B], Rows).

This can compile to simple nested loops or table iteration. That is Apple IIe-friendly.

What should not live fully on the Apple IIe:

full Prolog engine
general backtracking
large unification
large symbolic term database
large findall buffers

A practical Detlog for Apple IIe would support:

facts
small lists
simple unification
deterministic calls
member_cp choice packets
splice
loop exiters instead of cut
optional final member enumeration

With floppy: comfortable for loading compiler passes, source files, generated BASIC/assembly, and examples.

Without floppy: possible, but much smaller: type-in programs, cassette, or ROM/RAM-resident mini-Detlog. The compiler must be tiny, and examples should be small.

Best conclusion:

Detlog is more realistic than Prolog on an Apple IIe because it removes hidden backtracking and compiles cognitive Prolog syntax into BASIC-like or 6502-like deterministic loops.

What is the memory usage difference between running it on BASIC or 6502?

Approximate difference:

6502 assembly Detlog runtime:
~1 KB to 8 KB for a small engine
Applesoft BASIC Detlog runtime:
~8 KB to 25+ KB for the same logic

Why BASIC uses more memory:

BASIC stores tokenised program lines
line numbers cost memory
variables/arrays use interpreter structures
strings/lists are expensive
loops are interpreted, not native

Why 6502 uses less:

direct bytes/instructions
compact arrays
manual stack layout
no BASIC line overhead
faster deterministic loops
smaller choice-packet/splice routines

Example:

a(A) :- member_cp(A,[1,2]).
b(B) :- member_cp(B,[3,4]).

In BASIC, [1,2] and [3,4] become arrays plus loop code.

In 6502, they can be:

A_TABLE: .byte 1,2
B_TABLE: .byte 3,4

Very compact.

Best practical split:

Use BASIC version:
for teaching, readability, easy editing.
Use 6502 version:
for real speed, lower memory, larger Detlog programs.

Rule of thumb:

6502 assembly may use 3× to 10× less memory than BASIC for the same compiled Detlog program.

What is the most complex program including loops and strings allowed on 6502?

On a 64 KB Apple IIe, a realistic 6502 Detlog limit is roughly:

Program code: 4–16 KB
Runtime library: 2–8 KB
Data/tables: 8–24 KB
Strings heap: 4–16 KB
Stack/workspace: 2–8 KB
Screen/OS overhead: remaining memory

So the “comfortable” maximum is a program with:

50–300 simple rules
10–100 small facts/tables
nested loops over small lists
strings mostly under 40–255 chars
total working data under ~16–32 KB

Example of a safe complex Detlog shape:

word("cat").
word("dog").
suffix("s").
suffix("ed").
make_word(W2) :-
word(W),
suffix(S),
concat(W,S,W2).
main(Out) :-
word(W0),
suffix(S0),
splice([W0,S0], Rows),
member([W,S], Rows),
concat(W,S,Out).

Compiled to 6502, this is fine because it becomes:

loop over word table
loop over suffix table
copy string W
append string S
print/store result

A hard but possible upper example:

3–5 nested loops
several string tables
simple unification
small parser/tokeniser
choice-packet splicing
final member-style enumeration

What becomes uncomfortable:

large recursive parse trees
general Prolog unification
deep term copying
large findall-style result sets
many long strings
dynamic database updates

Best rule:

On 6502, Detlog can support small cognitive symbolic programs, not large general Prolog systems.

For Apple IIe Detlog, the ideal design is:

compile rules to fixed loops
store facts as compact tables
store strings once
avoid heap allocation inside loops
splice early
enumerate late

What do avoid heap allocation inside loops and enumerate late mean?

These are classic compiler optimisations that fit Detlog very well.

Avoid heap allocation inside loops

Suppose you write:

word(W) :-
member_cp(W, ["cat","dog"]).
suffix(S) :-
member_cp(S, ["s","ed"]).
main(X) :-
word(W),
suffix(S),
concat(W,S,X).

A naïve implementation does:

loop
allocate string "cats"
loop
allocate string "cated"
loop
allocate string "dogs"
loop
allocate string "doged"

Every iteration asks the heap for more memory.

Instead:

allocate one buffer
reuse it every iteration

Pseudo-6502:

buffer[32]
copy "cat" to buffer
append "s"
print
copy "cat" to buffer
append "ed"
print

No new memory is created inside the loop.

Benefits:

less RAM
less fragmentation
faster execution

This was especially important on machines like the Apple IIe.

⸻

Enumerate late

Traditional Prolog:

a(A) :- member(A,[1,2]).
b(B) :- member(B,[3,4]).
c(A,B) :-
a(A),
b(B).

immediately generates:

A=1,B=3
A=1,B=4
A=2,B=3
A=2,B=4

Detlog instead keeps choices packed:

A = cp([1,2])
B = cp([3,4])

Then:

splice([A,B], Rows).

gives:

Rows = [[1,3],[1,4],[2,3],[2,4]]

The program works on Rows for as long as possible.

Only at the very end:

member([A,B], Rows).

do we produce individual answers.

That’s “enumerate late”.

Instead of:

generate answer
generate answer
generate answer
generate answer

we do:

build compact structure
process compact structure
enumerate only when needed

⸻

In Detlog terms

A useful slogan is:

Splice early, enumerate late.

and

Allocate once, reuse inside loops.

These two rules make a huge difference on a 6502 because CPU speed and RAM are both extremely limited. They also fit your Detlog philosophy of replacing hidden backtracking with explicit deterministic structures.

Could you avoid heap allocation inside loops by using decision tree-type compression (like S2A)?

Yes. Decision-tree/S2A-style compression is one of the best ways to avoid heap allocation inside loops.

Instead of building strings each time:

cat + s = cats
cat + ed = cated
dog + s = dogs
dog + ed = doged

Detlog can compile shared prefixes into a decision tree/trie:

    start
   /     \
cat       dog

/ \ / \
s ed s ed

Then the loop does not allocate "cats" or "doged" as new heap strings. It walks the tree and emits/copies characters into one fixed output buffer.

So:

concat(W,S,Out)

can compile to:

select W branch
select S branch
write chars to reusable buffer
print/output

For 6502, this is ideal:

string table in ROM/RAM
decision tree indexes
one output buffer
no per-iteration heap allocation

S2A helps because it can discover repeated structure:

cat-s
cat-ed
dog-s
dog-ed

becomes:

word branch + suffix branch

rather than four separate allocated strings.

Best Detlog rule:

Use S2A compression to turn repeated generated outputs into shared decision paths, then use loops only to walk those paths.

So yes: decision-tree compression can replace many heap allocations with table lookup, branch selection, and buffer reuse.

Do the same operation from different clauses once, perhaps using decision-tree compression. For example, a:-a1,a2.b:-a1,b2.->ab:-a1,ab2.ab2:-a2.ab2:-b2.

Yes — this is common-prefix factoring across clauses.

Original:

a :- a1, a2.
b :- a1, b2.

Both clauses repeat:

So Detlog can factor it once:

ab :-
a1,
ab2.
ab2 :-
a2.
ab2 :-
b2.

Meaning:

run a1 once
then choose between a2 and b2

This is like decision-tree compression:

Before:
a -> a1 -> a2
b -> a1 -> b2
After:
ab -> a1 -> choice(a2,b2)

So the compiler optimisation is:

If several clauses share the same prefix, execute the shared prefix once, then splice/branch only at the differing suffixes.

For Detlog, this matters because it avoids:

run a1 for a
run a1 for b

and replaces it with:

run a1 once
then continue with alternatives

A more Detlog-shaped version:

ab :-
once_det(a1),
splice_branch([a2, b2]).

or:

ab :-
a1,
choice([a2, b2]).

General rule:

p :- x, y.
q :- x, z.

becomes:

pq :-
x,
pq2.
pq2 :- y.
pq2 :- z.

This is exactly the same idea as trie compression for strings, but applied to predicate sequences instead of characters.

With decision tree compression, how long can programs be if the compiler compiles Detlog into 6502?

With decision-tree compression, Detlog compiled to 6502 could be much larger:

Comfortable: about 10–40 KB Detlog source logic
Possible with careful tables/overlays: 50–100 KB+ source logic
Resident 6502 code/data at once: still roughly 20–40 KB usable RAM on a 64 KB Apple IIe.

The trick is that repeated clauses like:

a :- common, x1.
b :- common, x2.
c :- common, x3.

do not compile into three full copies. They compile more like:

run common once
branch/table-select x1/x2/x3
reuse output buffers

So the source can be much longer than the resident machine code.

A useful estimate:

Without compression: source × 3–20 expansion
With compression: source × 0.5–3 expansion
Best case: many repeated clauses collapse into tables
Worst case: unique clauses still expand normally

So on Apple IIe:

Tiny runtime/compiler stub: 2–8 KB
Decision tables + code: 10–30 KB
Buffers/stacks/strings: 4–16 KB
Overlay/floppy-loaded chunks: much larger total program

The biggest realistic Detlog programs would be table-heavy grammars, classifiers, menu systems, small adventure games, symbolic transformers, or bounded expert systems.

The key limit becomes not “how long is the source?” but:

How much must be resident at once?
How large are the strings?
How deep are loops/recursion?
How many choicepoints must be remembered?
How much output buffering is needed for splicing?

So the practical answer is:

With decision-tree compression, a Detlog program can feel like tens of KB of logic on a 64 KB Apple IIe, and possibly hundreds of KB if split into floppy-loaded overlays.

Is Detlog the most efficient Apple IIe Prolog?

Potentially, yes in a narrow sense, but it depends on what you mean by “Prolog.”

Traditional Prolog systems on 6502 machines (including Apple II-era implementations) typically support:

Full unification
Backtracking
Choicepoint stacks
Dynamic search
Variable bindings and trail management

These features make Prolog expressive, but they consume memory and CPU time.

If Detlog:

Converts nondeterminism into deterministic loops,
Eliminates most or all runtime choicepoints,
Compiles directly to 6502 machine code,
Uses decision-tree compression,
Avoids heap allocation inside loops,
Reuses buffers and tables,

then it could easily outperform a traditional Prolog implementation on an Apple IIe in both speed and memory use.

A rough spectrum is:

System Runtime Cost Expressiveness
BASIC interpreter High Low
Interpreted Prolog Very high Very high
Compiled Prolog Moderate Very high
Deterministic Detlog Low Medium–high
Hand-written 6502 assembly Lowest Depends on programmer

The important caveat is that Detlog’s efficiency comes partly from restricting or transforming classic Prolog behavior. If a program relies heavily on arbitrary unification, open-ended backtracking, or runtime search, then either:

Detlog cannot compile it directly, or
The compiler must generate additional machinery, reducing the advantage.

For the kinds of programs you’ve described in relation to Loop2 and PLOP—decision trees, classifiers, CFG/DCG-style parsing, symbolic transformations, specification-to-algorithm generation, and deterministic splicing—Detlog could be among the most efficient Prolog-like systems feasible on an Apple IIe.

In fact, if the compiler can transform:

colour(red).
colour(green).
colour(blue).

into a compact lookup table or decision tree rather than runtime backtracking, the resulting 6502 code is closer to an optimized expert system than a traditional Prolog engine.

So a reasonable conclusion is:

Detlog is unlikely to be the most efficient implementation of full Prolog on an Apple IIe, because full Prolog requires general unification and backtracking. However, it could be one of the most efficient Prolog-derived logic languages for a large class of deterministic and semi-deterministic programs, especially if it combines direct 6502 compilation, decision-tree compression, and elimination of runtime choicepoints.

What "length" of program is possible with decision tree, Loop2 and PLOP compression?

With decision tree + Loop2 + PLOP compression, the practical “length” could be:

Resident on 64 KB Apple IIe:
20–60 KB of effective Detlog logic
With very careful memory layout:
60–150 KB effective logic
With floppy overlays / paged modules:
hundreds of KB, possibly 0.5–1 MB+ total project logic

The key distinction:

Physical 6502 code resident at once: still maybe 10–35 KB
Effective Detlog source represented: much larger

Why? Because the compiler can merge repeated structures:

a :- common, a1.
b :- common, b1.
c :- common, c1.

into something closer to:

run common once
select branch from compressed decision table
run only the differing suffix
reuse buffers

So the expansion changes roughly like this:

Naive Detlog → 6502:
source × 3–20
Decision-tree compression:
source × 0.5–3
Decision tree + Loop2 + PLOP:
source × 0.1–2 in good cases

Best cases are classifiers, grammars, menu trees, symbolic rewrite systems, adventure-game logic, deterministic parsers, and repeated clause families.

Worst cases are programs where every clause is unique, string-heavy, deeply recursive, or requires true Prolog backtracking.

So the answer is:

Physically, the Apple IIe still runs tens of KB at once. Logically, Detlog could represent hundreds of KB of Prolog-like program behaviour if PLOP/Loop2 compress repeated choicepoints into loops, tables, and shared suffix/prefix code.

O(1) is the simplest complexity that Prolog Optimisation results in

Lucian Green — Tue, 26 May 2026 01:24:53 +0000

See Prolog Optimisation (plop)

O(1) is the simplest complexity that Prolog Optimisation results in

Courtesy ChatGPT.

The simplest complexity your matrix/indexical computation can result in is:

O(1)

—but only after successful symbolic collapse.

The progression is roughly:

Stage Complexity
Recursive traversal O(n), O(n²), O(tree size)
Indexed access O(depth)
Grouped extraction O(shared depth + outputs)
Memoised reuse amortised near O(1)
Closed-form formula discovery O(1)

The key observation is:

Your optimiser tries to convert traversal complexity into coordinate complexity.

For example:

nth1(I, Matrix, Row),
nth1(J, Row, X)

Normally:

O(I + J)

because lists are traversed.

But after indexical optimisation:

subterm_with_address(Matrix,[I,J],X)

you conceptually reduce it to:

O(depth)

where depth is just the nesting depth:

for a matrix.

Then if the optimiser replaces the whole traversal with a formula:

S is N*(N+1)//2

the complexity becomes:

O(1)

because no traversal remains.

The deepest idea in your system is:

recursive structure
→ address space
→ grouped address space
→ algebraic formula

Example:

findall(I, between(1,N,I), L),
sum_list(L,S)

starts as:

O(N)

Then:

between(1,N,I)

becomes an index sequence:

1,2,3,...,N

Gaussian elimination discovers:

S=\frac{N(N+1)}{2}

which is:

O(1)

So your optimiser is essentially trying to discover when:

computation = hidden geometry

and then compress the geometry into algebra.

For recursive trees:

tree traversal

normally costs:

O(number of visited nodes)

But if only needed addresses are extracted:

needed_subterms(Tree, Addresses, Values)

then complexity becomes approximately:

O(number of needed paths × average depth)

and grouped extraction reduces repeated prefixes:

O(shared prefix depth + differing suffixes)

So the optimiser tends toward:

output-sensitive complexity

where cost depends on:

needed outputs

rather than:

entire structure size

That is very similar to sparse neural attention.

The theoretical lower bound for your approach is:

O(size of final irreducible information)

because if the output itself contains k independent values, you must at least construct those k values.

So the optimiser approaches O(1) when:

the result can be expressed algebraically,
or fully memoised,
or directly addressed,
or reconstructed from grouped subterms,
or compressed into symbolic coordinates.

NeuroProlog + Starlog Demo

Lucian Green — Wed, 22 Apr 2026 13:59:39 +0000

Courtesy of ChatGPT.

1. Load Starlog


bash
cd /path/to/Starlog
swipl
?- use_module(starlog).
true.

⸻

2. Starlog string concatenation

?- starlog_call(A is "x":"y").
A = "xy".

⸻

3. Starlog list append

?- starlog_call(L is [1] & [2]).
L = [1, 2].

⸻

4. Starlog atom concatenation

?- starlog_call(A is a • b).
A = ab.

⸻

5. Starlog arithmetic

?- starlog_call(X is 1+2).
X = 3.

⸻

6. Starlog nested functions

?- starlog_call(X is reverse(reverse([1,2,3]))).
X = [1, 2, 3].
?- starlog_call(X is length(reverse([1,2,3]))).
X = 3.

⸻

7. Starlog method chaining

?- starlog_call(R is reverse([1,2,3]) >> length).
R = 3.
?- starlog_call(R is ([1,2] & [3,4]) >> reverse >> length).
R = 4.

⸻

8. Starlog evaluation

?- starlog_eval("hello":"world", R).
R = "helloworld".
?- starlog_eval([a] & [b,c], R).
R = [a, b, c].

⸻

9. Starlog no-eval

?- starlog_no_eval(1+1, R).
R = 1+1.
?- starlog_no_eval("x":"y", R).
R = "x":"y".

⸻

10. Starlog forced eval inside no-eval

?- starlog_call(R is no_eval(eval(1+1) + 3)).
R = 2+3.

⸻

11. Starlog result capture

?- starlog_call(X is "hello":"world", R).
R = "helloworld".
?- starlog_call(Y is [1,2] & [3,4], R).
R = [1, 2, 3, 4].

⸻

12. Starlog dual expression solving

?- starlog_call(([1] & A) is (B & [2])).
A = [2],
B = [1].
?- starlog_call((A : a : C) is (b : a : c)).
A = b,
C = c.

⸻

13. Starlog find first solution

?- starlog_call(Result is find(X, member(X, [1,2,3]))).
Result = 1.
?- starlog_call(Result is find(R, starlog_call(R is "hello":"world"))).
Result = "helloworld".

⸻

14. Starlog find with pattern extraction

?- starlog_call(Result is find([A,C], starlog_call([A:a:C] is [a:a:c]))).
Result = [a, c].
?- starlog_call(Result is find([A,C], starlog_call([A:"_":C] is ["hello":"_":"world"]))).
Result = ["hello", "world"].

⸻

15. Starlog term construction

?- starlog_call(T is ..=([f,0,1])).
T = f(0, 1).
?- starlog_call(L is =..(f(0,1))).
L = [f, 0, 1].

⸻

16. Starlog expansion inspection

?- starlog_show_expansion(A is "x":"y").
string_concat("x", "y", A).

⸻

17. Starlog output code

?- starlog_output_code(string_concat("x","y",A), Code).
Code = (A is "x":"y").

⸻

18. Starlog Prolog-to-Starlog conversion

?- convert_prolog_to_starlog(string_concat("x","y",A), Starlog).
Starlog = (A is "x":"y").
?- convert_prolog_to_starlog(append([1],[2],L), Starlog).
Starlog = (L is [1]&[2]).

⸻

19. Starlog Gaussian elimination

Load the Gaussian module:

?- use_module(gaussian_elimination).
true.

Solve:

x + y = 2
2x + 3y = 5
?- solve_system([[1,1,2],[2,3,5]], Solution).
Solution = [1, 1].

⸻

20. Starlog row reduction

?- gaussian_elimination([[1,1,2],[2,3,5]], R).
R = [[1,1,2],[0,1,1]].

⸻

21. Starlog polynomial reconstruction

?- npl_reconstruct_polynomial(n, [0,0.5,0.5], Expr).
Expr = n*(n+1)/2.

⸻

22. Starlog polynomial validation

?- npl_validate_polynomial_fit([1-1,2-3,3-6], [0,0.5,0.5], n, Result).
Result = valid.

⸻

23. Starlog symbolic indexing

?- npl_assign_symbolic_indices([a,b,c], Indexed, Map).
Indexed = indexed([a,b,c]),
Map = map(_).

⸻

24. Starlog reduce goal to irreducibles

?- npl_reduce_predicate_to_pattern_irreducibles((member(X,[1,2]), X > 0), R).
R = reduced(sequence(_, _)).

⸻

25. Starlog trace index flow

?- npl_assign_symbolic_indices([a,b,c], Indexed, Map),
   npl_trace_index_flow(member(X,[a,b,c]), Map, Flow).
Indexed = indexed([a,b,c]),
Map = map(_),
Flow = flow_graph(_, _, _, trace(_)).

⸻

26. Starlog identify independent indices

?- npl_identify_independent_indices(flow([x-1,y-2]), Indices).
Indices = [i].

⸻

27. Starlog reconstruct index relations

?- npl_reconstruct_index_relations(flow([x-[1,2,3], y-[4,5,6]]), [i], Relations).
Relations = [_].

⸻

28. Starlog direct indexed rule

?- npl_reconstruct_direct_indexed_rule([x-(i+1)], [i], Rule).
Rule = direct_index_rule([x-(i+1)], coefficient_metadata([i])).

⸻

29. Starlog Stage 8 pipeline order

?- npl_stage8_pipeline_order(Order).
Order = [
  symbolic_index_assignment,
  pattern_irreducible_reduction,
  index_flow_tracing,
  independent_index_detection,
  relation_reconstruction,
  ir_build,
  ir_lowering
].

⸻

30. Starlog Stage 8 build IR

?- npl_stage8_build_ir(flow([]), [i], [x-(i+1)], [0,1], [], IR).
IR = ir_pipeline(_, _, meta(_)).

⸻

31. Starlog Stage 8 lower IR

?- IR = ir_pipeline([], [ir_poly_eval(n,[0,0.5,0.5],result)], meta([])),
   npl_stage8_lower_ir(IR, Lowered).
Lowered = lowered_ir([lowered_poly_eval(n, [0,0.5,0.5], result)]).

⸻

32. Starlog Stage 9 code generation

?- IR = lowered_ir([lowered_poly_eval(n, [0,0.5,0.5], result)]),
   npl_stage9_generate_code(IR, Code).
Code = generated_program([assign(result, n*(n+1)/2)]).

⸻

33. Starlog Stage 9 neurocode emission

?- IR = lowered_ir([lowered_poly_eval(n, [0,0.5,0.5], result)]),
   npl_stage9_emit_neurocode(IR, Neurocode).
Neurocode = neurocode([neuro_assign(result, n*(n+1)/2)]).

⸻

34. Starlog Stage 9 compile IR

?- IR = lowered_ir([lowered_poly_eval(n, [0,0.5,0.5], result)]),
   npl_stage9_compile_ir(IR, Neurocode).
Neurocode = neurocode([neuro_assign(result, n*(n+1)/2)]).

⸻

35. Starlog annotated source text

?- IR = lowered_ir([lowered_poly_eval(n, [0,0.5,0.5], result)]),
   Context = [source_file('examples/generated_input.pl'),
              optimisation_report('stage9_codegen')],
   npl_ir_to_annotated_source_text(IR, Context, Text).
Text = "...".

⸻

36. Starlog annotated source file

?- IR = lowered_ir([direct_index_rule(index_spec([i]),
                                      [x-(i+1)],
                                      result_collector(rows))]),
   Context = [source_file('examples/generated_input.pl')],
   npl_ir_to_annotated_source_file(IR, Context, 'out/annotated_stage9.pl').
true.

⸻

37. Starlog Stage 10 integration option

?- npl_stage10_integration_option(Option).
Option = option_b_port_and_align.
?- npl_stage10_gaussian_canonical_repository(Repo).
Repo = starlog.

⸻

38. Starlog Stage 12 transform decision

?- npl_stage12_transform_decision([deterministic, proven_equivalent, coefficients_valid], Decision).
Decision = transform.
?- npl_stage12_transform_decision([side_effecting], Decision).
Decision = do_not_transform.

⸻

39. Starlog Stage 13 toggleable passes

?- npl_stage13_toggleable_passes(Passes).
Passes = [
  pass(gaussian_elimination, true),
  pass(recursion_to_loop, true),
  pass(subterm_index_optimisation, true),
  pass(annotated_regeneration, true)
].

⸻

40. Starlog Stage 13 effective toggles

?- npl_stage13_effective_pass_toggles([pass(gaussian_elimination,false)], Toggles).
Toggles = [
  pass(gaussian_elimination, false),
  ...
].

⸻

NeuroProlog commands

41. Load NeuroProlog

cd /path/to/neuroprolog
swipl
?- consult('src/neuroprolog').
true.

⸻

42. Load main optimisation modules

?- use_module('src/gaussian_recursion').
true.
?- use_module('src/memoisation').
true.
?- use_module('src/subterm_addressing').
true.
?- use_module('src/nested_recursion').
true.
?- use_module('src/optimiser').
true.
?- use_module('src/optimiser_pipeline').
true.

⸻

43. Full optimiser

?- IR = [ir_clause(p, ir_seq(ir_true, ir_call(q)), info([]))],
   npl_optimise(IR, OptIR).
IR = [ir_clause(p, ir_seq(ir_true, ir_call(q)), info([]))],
OptIR = [ir_clause(p, ir_call(q), info([]))].
?- IR = [ir_clause(p, ir_disj(ir_fail, ir_call(q)), info([]))],
   npl_optimise(IR, OptIR).
IR = [ir_clause(p, ir_disj(ir_fail, ir_call(q)), info([]))],
OptIR = [ir_clause(p, ir_call(q), info([]))].
?- IR = [ir_clause(p, ir_if(ir_true, ir_call(q), ir_call(r)), info([]))],
   npl_optimise(IR, OptIR).
IR = [ir_clause(p, ir_if(ir_true, ir_call(q), ir_call(r)), info([]))],
OptIR = [ir_clause(p, ir_call(q), info([]))].

⸻

44. Compile a file

?- npl_compile('examples/hello.pl', 'neurocode/hello_nc.pl').
true.

⸻

45. Compile with pipeline config

?- npl_pipeline_default_config(Cfg),
   npl_compile_with_pipeline('examples/lists.pl', 'neurocode/lists_nc.pl', Cfg).
Cfg = ...,
true.

⸻

46. Safe compile

?- npl_compile_safe('examples/lists.pl', 'neurocode/lists_safe_nc.pl').
true.

⸻

47. Pipeline config

?- npl_pipeline_default_config(Cfg).
Cfg = ...

⸻

48. Disable a pass

?- npl_pipeline_default_config(Cfg0),
   npl_pipeline_disable(gaussian_elimination, Cfg0, Cfg1).
Cfg0 = ...,
Cfg1 = ...

⸻

49. Enable a pass

?- npl_pipeline_default_config(Cfg0),
   npl_pipeline_enable(subterm_address_conversion, Cfg0, Cfg1).
Cfg0 = ...,
Cfg1 = ...

⸻

50. Run pipeline manually

?- npl_pipeline_default_config(Cfg),
   IR = [ir_clause(p, ir_seq(ir_true, ir_call(q)), info([]))],
   npl_pipeline_run(Cfg, IR, OptIR, Report).
Cfg = ...,
OptIR = [ir_clause(p, ir_call(q), info([]))],
Report = ...

⸻

51. Run full pipeline

?- npl_pipeline_default_config(Cfg),
   IR = [ir_clause(p, ir_seq(ir_true, ir_call(q)), info([]))],
   npl_pipeline_run_full(Cfg, IR, OptIR, Neurocode, Report).
Cfg = ...,
OptIR = [ir_clause(p, ir_call(q), info([]))],
Neurocode = ...,
Report = ...

⸻

52. Dictionary simplification rules

?- npl_opt_dict_rules(Rules).
Rules = ...

⸻

53. Apply dictionary rules

?- IR = [ir_clause(test, ir_seq(ir_true, ir_call(goal)), info([]))],
   npl_opt_dict_rules(Rules),
   npl_apply_rules(Rules, IR, OptIR).
IR = [ir_clause(test, ir_seq(ir_true, ir_call(goal)), info([]))],
Rules = ...,
OptIR = [ir_clause(test, ir_call(goal), info([]))].
?- IR = [ir_clause(test, ir_disj(ir_fail, ir_call(goal)), info([]))],
   npl_opt_dict_rules(Rules),
   npl_apply_rules(Rules, IR, OptIR).
IR = [ir_clause(test, ir_disj(ir_fail, ir_call(goal)), info([]))],
Rules = ...,
OptIR = [ir_clause(test, ir_call(goal), info([]))].
?- IR = [ir_clause(test, ir_if(ir_true, ir_call(a), ir_call(b)), info([]))],
   npl_opt_dict_rules(Rules),
   npl_apply_rules(Rules, IR, OptIR).
IR = [ir_clause(test, ir_if(ir_true, ir_call(a), ir_call(b)), info([]))],
Rules = ...,
OptIR = [ir_clause(test, ir_call(a), info([]))].

⸻

54. Gaussian recursion classification

?- Group = [
      ir_clause(count(0), ir_true, info([])),
      ir_clause(count(N),
                ir_seq(ir_call(gt(N,0)),
                       ir_seq(ir_call(is(N1,N-1)),
                              ir_call(count(N1)))),
                info([]))
   ],
   npl_is_reducible(Group, Pattern).
Group = [...],
Pattern = linear_tail_recursion.

⸻

55. Gaussian recursion reduction

?- Group = [
      ir_clause(sum([],0), ir_true, info([])),
      ir_clause(sum([H|T],S),
                ir_seq(ir_call(sum(T,S1)),
                       ir_call(is(S, +(S1,H)))),
                info([]))
   ],
   npl_gaussian_reduce(Group, Reduced).
Group = [...],
Reduced = ...

⸻

56. Gaussian elimination matrix

?- Matrix = [
      [frac(1,1), frac(1,1), frac(2,1)],
      [frac(2,1), frac(3,1), frac(5,1)]
   ],
   npl_gauss_eliminate(Matrix, R).
Matrix = [[frac(1,1), frac(1,1), frac(2,1)],
          [frac(2,1), frac(3,1), frac(5,1)]],
R = ...

Expected mathematical output:

x = 1
y = 1

⸻

57. Gaussian polynomial discovery

?- Matrix = [
      [frac(1,1), frac(1,1), frac(1,1), frac(1,1)],
      [frac(4,1), frac(2,1), frac(1,1), frac(3,1)],
      [frac(9,1), frac(3,1), frac(1,1), frac(6,1)]
   ],
   npl_gauss_eliminate(Matrix, R).
Matrix = [[frac(1,1), frac(1,1), frac(1,1), frac(1,1)],
          [frac(4,1), frac(2,1), frac(1,1), frac(3,1)],
          [frac(9,1), frac(3,1), frac(1,1), frac(6,1)]],
R = ...

Expected mathematical output:

a = 1/2
b = 1/2
c = 0
S(n) = n(n+1)/2

⸻

58. Arithmetic sequence discovery

?- Matrix = [
      [frac(1,1), frac(1,1), frac(1,1)],
      [frac(2,1), frac(1,1), frac(3,1)]
   ],
   npl_gauss_eliminate(Matrix, R).
Matrix = [[frac(1,1), frac(1,1), frac(1,1)],
          [frac(2,1), frac(1,1), frac(3,1)]],
R = ...

Expected mathematical output:

f(n) = 2n - 1

⸻

59. 2D index formula discovery

?- Matrix = [
      [frac(1,1), frac(1,1), frac(2,1)],
      [frac(2,1), frac(1,1), frac(4,1)]
   ],
   npl_gauss_eliminate(Matrix, R).
Matrix = [[frac(1,1), frac(1,1), frac(2,1)],
          [frac(2,1), frac(1,1), frac(4,1)]],
R = ...

Expected mathematical output:

f(i) = 2i

⸻

60. Quadratic loop formula discovery

?- Matrix = [
      [frac(1,1), frac(1,1), frac(1,1), frac(1,1)],
      [frac(4,1), frac(2,1), frac(1,1), frac(4,1)],
      [frac(9,1), frac(3,1), frac(1,1), frac(9,1)]
   ],
   npl_gauss_eliminate(Matrix, R).
Matrix = [[frac(1,1), frac(1,1), frac(1,1), frac(1,1)],
          [frac(4,1), frac(2,1), frac(1,1), frac(4,1)],
          [frac(9,1), frac(3,1), frac(1,1), frac(9,1)]],
R = ...

Expected mathematical output:

T(n) = n^2

⸻

61. Nested recursion classification

?- Group = [
      ir_clause(fib(0,0), ir_true, info([])),
      ir_clause(fib(1,1), ir_true, info([])),
      ir_clause(fib(N,R),
        ir_seq(ir_call(is(N1, -(N,1))),
        ir_seq(ir_call(fib(N1,R1)),
        ir_seq(ir_call(is(N2, -(N,2))),
        ir_seq(ir_call(fib(N2,R2)),
               ir_call(is(R, +(R1,R2))))))),
        info([]))
   ],
   npl_nested_classify(Group, Class).
Group = [...],
Class = nested_data_fold(+).

⸻

62. Nested recursion elimination

?- npl_nested_eliminate_pass(Group, OptGroup).
OptGroup = ...

⸻

63. Memoise predicate

?- npl_memo(fib/2).
true.

⸻

64. Memoise safe goal

?- npl_memo_call(member(a,[a,b,c])).
true.

⸻

65. Memoise deterministic result

?- npl_memo_call_det(length([1,2,3]), R).
R = 3.

⸻

66. Memoise all solutions

?- npl_memo_call_all(member(X,[a,b,c]), X, Solutions).
Solutions = [a,b,c].

⸻

67. Memoise explicit subgoal

?- npl_memo_subgoal(fib_20, fib(20, R)).
R = ...

⸻

68. Inspect memo cache

?- npl_memo_inspect(fib/2, Entries).
Entries = ...

⸻

69. Memo stats

?- npl_memo_stats(fib(20,_), Hits, Misses).
Hits = ...,
Misses = ...

⸻

70. Clear memo table

?- npl_memo_clear(fib/2).
true.

⸻

71. Clear all memo tables

?- npl_memo_clear_all.
true.

⸻

72. Memo safety

?- npl_memo_is_safe(member(a,[a,b,c])).
true.
?- npl_memo_is_safe(writeln(hello)).
false.

⸻

73. Memoisation pass over IR

?- IR = [ir_clause(fib(N,R), ir_call(fib_body(N,R)), info([]))],
   npl_memo(fib/2),
   npl_memoisation_pass(IR, OptIR).
IR = [ir_clause(fib(N,R), ir_call(fib_body(N,R)), info([]))],
OptIR = ...

⸻

74. Subterm-address conversion

?- IR = [
      ir_clause(tree_sum(T,S),
                ir_loop_candidate(
                    ir_seq(ir_call(arg(1,T,L)),
                    ir_seq(ir_call(tree_sum(L,SL)),
                           ir_call(true)))),
                info([]))
   ],
   npl_subterm_address_pass(IR, OptIR).
IR = [...],
OptIR = ...

⸻

75. Pattern correlation

?- IR = [
      ir_clause(p(a), ir_true, info([])),
      ir_clause(p(b), ir_true, info([]))
   ],
   npl_pattern_correlate(IR, OptIR).
IR = [ir_clause(p(a), ir_true, info([])),
      ir_clause(p(b), ir_true, info([]))],
OptIR = [ir_clause(p(a), ir_true, info([])),
         ir_clause(p(b), ir_true, info([]))].

⸻

76. Data unfolding

?- npl_unfold_data(ir_seq(ir_call(a), ir_call(b)), X).
X = ir_seq(ir_call(a), ir_call(b)).

⸻

77. Source file to IR

?- npl_lex('examples/lists.pl', Tokens),
   npl_parse(Tokens, AST),
   npl_analyse(AST, AAST),
   npl_intermediate(AAST, IR).
Tokens = ...,
AST = ...,
AAST = ...,
IR = ...

⸻

78. Source string to IR

?- npl_parse_string("p(X,Y) :- Y is X+0.", AST),
   npl_analyse(AST, AAST),
   npl_intermediate(AAST, IR).
AST = ...,
AAST = ...,
IR = [ir_clause(p(X,Y), ir_call(is(Y, X+0)), Info)].

⸻

79. Source string to optimised IR

?- npl_parse_string("p(X,Y) :- Y is X+0.", AST),
   npl_analyse(AST, AAST),
   npl_intermediate(AAST, IR),
   npl_optimise(IR, OptIR).
AST = ...,
AAST = ...,
IR = [ir_clause(p(X,Y), ir_call(is(Y, X+0)), Info)],
OptIR = [ir_clause(p(X,Y), ir_call(is(Y, X)), Info2)].

⸻

80. Fact to IR

?- npl_parse_string("foo(1).", AST),
   npl_analyse(AST, AAST),
   npl_intermediate(AAST, IR).
AST = ...,
AAST = ...,
IR = [ir_clause(foo(1), ir_true, Info)].

⸻

81. Conjunction to IR

?- npl_parse_string("p :- a, b.", AST),
   npl_analyse(AST, AAST),
   npl_intermediate(AAST, IR).
AST = ...,
AAST = ...,
IR = [ir_clause(p, ir_seq(ir_call(a), ir_call(b)), Info)].

⸻

82. If-then-else to IR

?- npl_parse_string("p :- (a -> b ; c).", AST),
   npl_analyse(AST, AAST),
   npl_intermediate(AAST, IR).
AST = ...,
AAST = ...,
IR = [ir_clause(p, ir_if(ir_call(a), ir_call(b), ir_call(c)), Info)].

⸻

83. Grouped IR

?- npl_parse_string("
     p(1).
     p(2).
     q(X) :- p(X).
   ", AST),
   npl_analyse(AST, AAST),
   npl_ir_full(AAST, FullIR).
AST = ...,
AAST = ...,
FullIR = [
  ir_predicate_def(p/1, ..., _),
  ir_predicate_def(q/1, ..., _)
].

⸻

84. End-to-end compile

swipl -g "consult('src/neuroprolog')" \
      -g "npl_compile('examples/lists.pl','neurocode/lists_nc.pl')" \
      -t halt

Output:

neurocode/lists_nc.pl

⸻

85. End-to-end safe compile

swipl -g "consult('src/neuroprolog')" \
      -g "npl_compile_safe('examples/lists.pl','neurocode/lists_safe_nc.pl')" \
      -t halt

Output:

neurocode/lists_safe_nc.pl

⸻

86. Run tests

swipl -g "consult('tests/run_tests')" -g "run_all_tests" -t halt

Output:

true.

⸻

Main command list

Starlog:

starlog_call/1
starlog_call/2
starlog_eval/2
starlog_no_eval/2
starlog_show_expansion/1
starlog_output_code/1
starlog_output_code/2
starlog_output_code/3
convert_prolog_to_starlog/2
solve_system/2
gaussian_elimination/2
npl_reconstruct_polynomial/3
npl_validate_polynomial_fit/4
npl_assign_symbolic_indices/3
npl_trace_index_flow/3
npl_reconstruct_index_relations/3
npl_stage8_build_ir/6
npl_stage8_lower_ir/2
npl_stage9_generate_code/2
npl_stage9_emit_neurocode/2
npl_stage9_compile_ir/2
npl_ir_to_annotated_source_text/3
npl_ir_to_annotated_source_file/3

NeuroProlog:

npl_compile/2
npl_compile_with_pipeline/3
npl_compile_safe/2
npl_optimise/2
npl_pipeline_default_config/1
npl_pipeline_enable/3
npl_pipeline_disable/3
npl_pipeline_run/4
npl_pipeline_run_full/5
npl_opt_dict_rules/1
npl_apply_rules/3
npl_apply_rule/3
npl_gaussian_reduce/2
npl_is_reducible/2
npl_extract_recurrence/2
npl_gauss_eliminate/2
npl_nested_classify/2
npl_nested_eliminate_pass/2
npl_memo/1
npl_memo_call/1
npl_memo_call_det/2
npl_memo_call_all/3
npl_memo_subgoal/2
npl_memo_inspect/2
npl_memo_stats/3
npl_memo_clear/1
npl_memo_clear_all/0
npl_memoisation_pass/2
npl_subterm_address_pass/2
npl_pattern_correlate/2
npl_unfold_data/2
npl_parse_string/2
npl_lex/2
npl_parse/2
npl_analyse/2
npl_intermediate/2
npl_ir_full/2

Core idea:

Starlog gives readable syntax.
NeuroProlog turns readable logic into optimised IR, neurocode, formulas, memoised calls, and direct indexed rules.

How do pl2js and Tau Prolog compare?

Lucian Green — Mon, 30 Mar 2026 14:04:41 +0000

How do pl2js and Tau Prolog compare?

ChatGPT: Here’s a clear, engineering-level comparison between your pl2js concept/repo and Tau Prolog:

⸻

🧠 Core Difference (1 sentence)
• pl2js = compiler/translator (Prolog → JS code)
• Tau Prolog = interpreter/runtime (executes Prolog directly in JS)

⸻

⚙️ Architecture Comparison

Execution Model

Tau Prolog
• Interprets Prolog at runtime
• Uses a Prolog engine implemented in JavaScript
• Backtracking, unification, etc. are simulated dynamically
• Non-blocking, callback-based execution model

pl2js (your design direction)
• Ahead-of-time conversion
• Prolog → explicit JS control flow
• loops instead of backtracking
• if/else instead of clause selection
• Similar philosophy to your pl2c:
• remove interpreter overhead
• flatten logic into imperative structures

👉 Key insight:
• Tau = simulate Prolog
• pl2js = eliminate Prolog

⸻

🚀 2. Performance Philosophy

Tau Prolog
• Slower (interpretive overhead)
• Flexible and dynamic
• Handles general Prolog features (ISO-oriented)

pl2js
• Potentially much faster
• Precompiled logic → direct execution
• Can optimise:
• repeated calls → functions
• choice points → loops
• data reuse → cached variables

👉 Your system aligns with:

“manual neuronet optimisation” + “Spec → Algorithm flattening”

⸻

🧩 3. Feature Completeness

Tau Prolog
• Designed toward ISO Prolog compliance
• Supports:
• modules
• DCGs
• meta-predicates
• async predicates
• DOM interaction

pl2js
• Likely:
• partial Prolog subset
• depends on what you convert
• Harder features:
• cut (!)
• dynamic predicates (assertz)
• meta-programming
• full unification edge cases

👉 Trade-off:
• Tau = completeness
• pl2js = controllable subset + optimisation

⸻

🌐 4. Web Integration

Tau Prolog
• Native browser integration:
• manipulate DOM from Prolog
• event handling
• Drop-in script usage

pl2js
• Output is plain JavaScript
• Integrates like any JS:
• React / HTML / mobile
• Better for:
• embedding in apps
• mobile (your goal: iPhone/Android)

⸻

🧪 5. Debugging & Transparency

Tau Prolog
• Debugging = Prolog-level
• Harder to inspect internal execution (black-box engine)

pl2js
• Debugging = JavaScript-level
• You can:
• log intermediate states
• inspect variables
• trace execution paths

👉 This aligns strongly with your:
• transparent MNN philosophy
• “no invisible bugs” goal

⸻

🧱 6. Control Over Execution

Tau Prolog
• Engine decides:
• backtracking order
• search strategy

pl2js
• YOU decide:
• loop structure
• branching
• memory usage
• determinism

👉 This is huge for:
• CI/CD
• deterministic systems
• optimisation pipelines

⸻

🧠 Strategic Insight (Important for Your Project)

Your system (pl2js) is not competing directly with Tau Prolog.

Instead:

Tau Prolog = “Prolog runtime for the web”

pl2js = “Prolog → optimised algorithm generator”

👉 In your ecosystem:
• Tau Prolog = execution layer
• pl2js = optimisation + deployment layer

⸻

🔥 Recommendation (based on your goals)

Given your:
• Spec → Algorithm vision
• MNN transparency goals
• CI/CD system (Lucian CI/CD)

👉 pl2js is the more aligned direction

Use Tau Prolog only if you need:
• quick prototyping
• full Prolog compatibility
• teaching/demo environments

⸻

💡 Advanced Hybrid Idea (Very Relevant to You)

You could combine both:
1. Prototype logic in Tau Prolog
2. Convert stable predicates via pl2js
3. Optimise with:
• Gaussian elimination
• recursion flattening
4. Deploy as pure JS

👉 This becomes:
Interpreter → Compiler → Optimiser pipeline

Prolog State Saving Interpreter is not strictly a graph interpreter

Lucian Green — Thu, 26 Mar 2026 03:05:53 +0000

Is Green's Prolog State Saving Interpreter a graph interpreter, given that it goes straight from choice-point to choice-point and exits predicates directly?

ChatGPT: Short answer: SSI is close to a graph interpreter, but not purely one—it’s better described as a choice-point–driven execution graph with stack/trace semantics hybridised in.

⸻

Why it looks like a graph interpreter

From your code, especially:
• Explicit choice point trail (Choice_point_trail)
• Direct jumps via:
• ssi1(...) calls
• get_last_cp_before_n
• delete_cp, cut_cps_if_necessary
• No strict reliance on recursive call stack unwinding
• Execution moves:
• from one choice point node → another
• sometimes skipping intermediate “call frames”

This gives you:

A non-linear control flow, where execution follows edges between states (choice points) rather than returning through a stack.

That is fundamentally graph-like execution.

⸻

But it is not a pure graph interpreter

A pure graph interpreter would:
• Represent predicates as nodes
• Represent control flow as explicit edges
• Evaluate by traversing a graph structure directly

SSI still retains:

Predicate-oriented structure

You still have:

d(...),
e(...),
ssi1(...)

These simulate predicate calls, even if you shortcut them.

Embedded stack semantics

Even though you jump, you still track:
• Level
• "returns to" metadata
• Pred_id chains

This is effectively a flattened / externalised call stack, not eliminated.

⸻

Choice points are graph nodes, but:

They are not the only control structure.

You also have:
• Variable environments (Vars, Globals)
• Predicate identity tracking (Pred_id)
• Structured transitions (predicate vs line)

So the system is:

A graph overlaid on a logical interpreter, not a pure graph VM.

⸻

The key insight (your system’s real nature)

SSI is best described as:

A control-flow graph interpreter over a logical program, using choice points as primary nodes and explicit state transitions instead of implicit backtracking.

Or more sharply:

A compiled Prolog execution graph with manual continuation passing.

⸻

Why your observation is still important

You said:

“it goes straight from choice point to choicepoint and exits predicates directly”

That’s the crucial shift:

Traditional Prolog:
• Stack-based
• Backtracking unwinds stack frames

SSI:
• Continuation-driven
• Choice points = resumable states
• Execution = jump to next valid continuation

That is a graph traversal.

⸻

Final classification

Property SSI
Stack-based interpreter ❌ (not primarily)
Graph interpreter ⚠️ partially
Continuation-passing interpreter ✅
Choice-point graph execution ✅
Pure dataflow/graph VM ❌

⸻

Clean conclusion

SSI is not strictly a graph interpreter, but it implements Prolog as a graph of continuations (choice points), effectively behaving like a graph interpreter with residual stack semantics.

⸻

Extra insight (important for your pl2c work)

This architecture is exactly why your idea works:
• You can compile SSI to C using loops + jumps
• Because:
• Choice points → labels
• Transitions → gotos / state machine
• No need for recursion

So SSI is already:

Halfway between Prolog and a state-machine compiler IR

⸻

If you want, I can:
• Formalise SSI as a graph IR (nodes + edges)
• Or show how to compile it into pure C loops with no recursion at all

Explain Recursive Structure Finding Algorithms

Lucian Green — Sun, 15 Mar 2026 09:39:45 +0000

Courtesy ChatGPT:
Explain Spec to Algorithm’s Context Free Grammar Generator’s top-down and bottom-up recursive structure finding algorithms. The top-down algorithm is:

find_lists3a(L1,L32,Rest) :-
    find_lists3(L1,[],L91,_Rest_a),
    (fail
    ->(L4=_L92,Flag=true);
    (L4=L91,Flag=false)),
    (L4=[]->L4=L3;
    (L4=[_L2]->L4=L3;
    (L4=[L2|L31],

    check14(L31,L2,[],L5,Rest),
    (L5=[['&r'|_]|_]->L5=L3;
    ((L5=[L51]->true;L51=L5),
    L3=[['&r',L51]]))
    ))),

    (Flag=true->L32=[['&r',L3]];L32=L3),
    !.

find_lists3([],L,L,_) :- !.
find_lists3(L1,L2,L3,Rest) :-
    repeating_unit(L1,U,Rest),
    (U=['&r',U1]->
    try(U1,U2);
    U2=U),
    append(L2,[['&r',U2]],L3).

match_char("[","]").
match_char("(",")").
match_char("{","}").
match_char(A,A).

find_lists3(L1,L2,L3,Rest) :-
    L1=[L4|L5],
    match_char(L4,L41),
    find_lists4(L2,L5,L4,L41,L3,Rest).

find_lists4(L2,L5,L4,L41,L3,Rest) :-
    member(L4,L5),
    sub_list(L5,Before_list,[L41],After_list),
    Before_list1=[L4|Before_list],After_list1=[L41|After_list],
    find_lists32(Before_list1,[],L6,_),
    find_lists3(After_list1,[],L7,Rest),
    foldr(append,[[L6,L7]],L8),
    foldr(append,[L2,L8],L33),
    L3=L33.
find_lists4(L2,L5,L4,L41,L3,Rest) :-
    not((member(L41,L5),
    sub_list(L5,_Before_list,[L4],_After_list))),   
    append(L2,[L4],L6),
    find_lists3(L5,L6,L3,Rest).

find_lists32(L1,L2,L3,Rest) :-
    find_lists3(L1,L2,L3,Rest).

repeating_unit(L1,U,Rest) :-
    (only_item(L1)->fail;
    (length(L1,L),
    L2 is (floor(L/2)),
    numbers(L2,1,[],Ns),
    find_first((member(N,Ns),
    split12(L1,N,[],A,Rest),
    maplist(=(_),A))),
    (N=L->U=L1;
    (length(L21,N),
    append(L21,_,L1),
    U=['&r',L21])))),!.

split12([],_,A,A,[]):-!.    
split12(L
,L16,
 A1,A2,_Rest) :- length(L,LL),LL<L16,
 append(A1,L,A2),
 !.
split12(Q2,L16,%N1,N2,
 L20,L17,Rest) :-
    length(L18,L16),
    append(L18,L19,Q2),
    append(L20,[L18],L21),
    split12(L19,L16,L21,L17,Rest),!.
split12(A,_B,C,C,A) :-!.

check14([],_,A,A,[]
):-!.
check14(A0,B,C,D1,Rest
) :-
    A0=[A01|A02],
    check141(A01,B,[],D),
    append(C,[D],C1),
    (check14(A02,B,C1,D1,Rest
    )
    ),
    !.
check141([],[],A,A):-!.
check141(A,B,C,D1) :-

append(A31,B3,A),append([A1],A2,B3),
append(A41,B4,B),append([B1],B2,B4),

((A31=[],A41=[])->A51=[];
(A31=[],not(A41=[]))->A51=A41;
(not(A31=[]),A41=[])->A51=A31),
    (A1=B1->(A3=A1,A2=A22,B2=B22
    );
    ((not(A1=['&r',_]),not(B1=['&r',_]))->fail;
    (
    ((A1=['&r',A11]->true;A1=A11),
    (B1=['&r',B11]->true;B1=B11),
    (not(is_list(A11))->(A11=A13
    ,(append([A21],A22,A2)->append([A13],[A21],A23);(A22=[],A23=[A13])
    ));(A11=A23,
    A22=A2
    )),
    (not(is_list(B11))->(B11=B13%,B14=[]
    ,(append([B21],B22,B2)->append([B13],[B21],B23);(B22=[],B23=[B13])
    ));(B11=B23,
    B22=B2
    )),
    check141(A23,B23,[],D),A3=['&r',D])))),
    (optional_s2g(on)->
    (A51=[]->A52=[];A52=[['&o',A51]]
    );
    (A51=[]->A52=[];fail
    )),
    foldr(append,[C,A52,[A3]],C1),

    check141(A22,B22,C1,D1),!.

And the bottom-up algorithm is:

find_lists3_optimized([], L, L, _) :- !.
find_lists3_optimized(L1, L2, L3, Rest) :-
    % Use optimized repeating_unit that tries smallest patterns first
    repeating_unit_optimized(L1, U, Rest),
    (U=['&r',U1] ->
        try(U1, U2);
        U2=U
    ),
    append(L2, [['&r',U2]], L3).

find_lists3_optimized(L1, L2, L3, Rest) :-
    L1=[L4|L5],
    match_char(L4, L41),
    find_lists4_optimized(L2, L5, L4, L41, L3, Rest).

% Optimized find_lists4 - reduce redundant processing
find_lists4_optimized(L2, L5, L4, L41, L3, Rest) :-
    member(L4, L5),
    sub_list(L5, Before_list, [L41], After_list),
    Before_list1=[L4|Before_list], After_list1=[L41|After_list],
    find_lists32_optimized(Before_list1, [], L6, _),
    find_lists3_optimized(After_list1, [], L7, Rest),
    foldr(append, [[L6,L7]], L8),
    foldr(append, [L2,L8], L33),
    L3=L33.
find_lists4_optimized(L2, L5, L4, L41, L3, Rest) :-
    not((member(L41, L5),
    sub_list(L5, _Before_list, [L4], _After_list))),    
    append(L2, [L4], L6),
    find_lists3_optimized(L5, L6, L3, Rest).

find_lists32_optimized(L1, L2, L3, Rest) :-
    find_lists3_optimized(L1, L2, L3, Rest).

% Optimized repeating_unit - bottom-up approach
% Key optimization: try patterns starting from length 1 (bottom-up)
repeating_unit_optimized(L1, U, Rest) :-
    (only_item(L1) -> fail;
    (length(L1, L),
    L2 is (floor(L/2)),
    % Bottom-up: try patterns starting from length 1
    try_pattern_lengths_bottomup(L1, 1, L2, U, Rest))), !.

% Try pattern lengths from 1 up to max (bottom-up approach)
try_pattern_lengths_bottomup(L1, CurrentLen, MaxLen, U, Rest) :-
    CurrentLen =< MaxLen,
    (try_pattern_length(L1, CurrentLen, U, Rest) ->
        true  % Found pattern at this length
    ;   NextLen is CurrentLen + 1,
        try_pattern_lengths_bottomup(L1, NextLen, MaxLen, U, Rest)
    ).

% Try a specific pattern length
try_pattern_length(L1, N, U, Rest) :-
    split12_optimized(L1, N, [], A, Rest),
    maplist(=(_), A),  % Check if all parts are the same
    (N=L1 -> 
        length(L1, L1Len),
        (N=L1Len -> U=L1;
        (length(L21, N),
        append(L21, _, L1),
        U=['&r', L21]))
    ; 
        (length(L21, N),
        append(L21, _, L1),
        U=['&r', L21])
    ).

% Optimized split12 - more efficient splitting
split12_optimized([], _, A, A, []) :- !.    
split12_optimized(L, L16, A1, A2, _Rest) :- 
    length(L, LL), 
    LL < L16,
    append(A1, L, A2), !.
split12_optimized(Q2, L16, L20, L17, Rest) :-
    length(L18, L16),
    append(L18, L19, Q2),
    append(L20, [L18], L21),
    split12_optimized(L19, L16, L21, L17, Rest), !.
split12_optimized(A, _B, C, C, A) :- !.

The top-down algorithm says, “Find the largest recursive explanation for the whole input, then refine,” while the bottom-up algorithm says, “Find the smallest repeating building blocks first, then assemble them into a larger recursive grammar structure.”

Video 1: The top-down algorithm says, “Find the largest recursive explanation for the whole input, then refine”.

Video 2: The bottom-up algorithm says, “Find the smallest repeating building blocks first, then assemble them into a larger recursive grammar structure.”

The bottom-up algorithm is much faster, as shown in the table below.
Top-Down
Bottom-Up
Strategy
Guess global structure
Build from data
Pattern search
Unordered
Small → large
Validation
After generation
During construction
Backtracking
Heavy
Minimal
Reuse
Poor
Strong
Complexity
Often exponential
Near polynomial">

Prolog "Mathematical Induction" Compression on Recursion

Lucian Green — Sat, 07 Mar 2026 12:54:56 +0000

See
https://github.com/luciangreen/mi
https://github.com/luciangreen/mi2
https://github.com/luciangreen/mi3

Below are concrete example predicates you can feed to each mi*.pl, and the typical outputs you would expect based on how each system works.

I’ll use the following test predicates because they represent the major classes of recursion:
1. numeric recursion (sum)
2. multiplicative recursion (factorial)
3. list recursion (length)
4. list recursion with head contribution (sumlist)
5. accumulator wrapper (reverse)
6. nested recursion (Fibonacci)

⸻

mi.pl (trace + polynomial fitting + pattern guessing)

Example 1 — Sum 1..N

Input

sum_to(0,0).
sum_to(N,S) :-
N>0,
N1 is N-1,
sum_to(N1,S1),
S is S1+N.

Call

?- analyze_predicates([sum_to(0,0),
(sum_to(N,S):-N>0,N1 is N-1,sum_to(N1,S1),S is S1+N)], R).

Typical Output

[
tagged(pattern(expr(nested,sum)), reusable(pattern_1234,3)),
tagged(pattern(expr(nested,sum)), reusable(pattern_5678,2))
]

Or after flattening / solving:

Closed form: n*(n+1)/2

This occurs because mi.pl traces values like:

N: 0 1 2 3 4
S: 0 1 3 6 10

and polynomial-fits them.

⸻

Example 2 — Factorial

Input

fact(0,1).
fact(N,R) :-
N>0,
N1 is N-1,
fact(N1,R1),
R is N*R1.

Output (approximate)

Closed form: factorial(N)

This usually comes from a placeholder recognizer:

recognize_factorial_pattern(...)

⸻

Example 3 — Fibonacci

Input

fib(0,0).
fib(1,1).
fib(N,F) :-
N>1,
fib(N-1,F1),
fib(N-2,F2),
F is F1+F2.

Typical output

Detected: nested recursion
Formula: unsupported / guessed

Or sometimes:

formula = ((phi^n - psi^n)/sqrt(5))

but this is pattern recognition, not derived mathematically.

⸻

mi2.pl (real recurrence extraction)

This system analyses clause structure.

⸻

Example 1 — Sum 1..N

Input

sum_to(0,0).
sum_to(N,S) :-
N>0,
N1 is N-1,
sum_to(N1,S1),
S is S1+N.

Call

?- analyze_predicate(Clauses, sum_to, 2, Analysis).

Output

analysis{
predicate:sum_to/2,
status:supported,
recurrence:recurrence{
domain:integer,
input_var:n,
base_cases:[base_case(0,0)],
step:step{
transform:dec(1),
combiner:add(current_n)
}
},
closed_form:closed_form{
kind:sum_1_to_n,
formula:n*(n+1)//2
}
}

⸻

Example 2 — Factorial

Input

fact(0,1).
fact(N,F) :-
N>0,
N1 is N-1,
fact(N1,F1),
F is N*F1.

Output

analysis{
predicate:fact/2,
status:supported,
recurrence:recurrence{
domain:integer,
base_cases:[base_case(0,1)],
step:step{
transform:dec(1),
combiner:multiply(current_n)
}
},
closed_form:closed_form{
kind:factorial,
formula:factorial(n)
}
}

⸻

Example 3 — List Length

Input

len([],0).
len([_|T],N) :-
len(T,N1),
N is N1+1.

Output

analysis{
predicate:len/2,
status:supported,
recurrence:recurrence{
domain:list,
base_cases:[base_case([],0)],
step:step{
transform:tail,
combiner:add(constant(1))
}
},
closed_form:closed_form{
kind:list_length,
formula:length_of(xs)
}
}

⸻

Example 4 — Fibonacci

Input

fib(0,0).
fib(1,1).
fib(N,F) :-
N>1,
fib(N-1,F1),
fib(N-2,F2),
F is F1+F2.

Output

analysis{
predicate:fib/2,
status:unsupported,
reason:nested_recursion
}

This is correct behaviour.

⸻

mi3.pl (pattern recognizer)

This is the system you recently debugged.

⸻

Example 1 — Sum

Input

sum_to(0,0).
sum_to(N,S) :-
N>0,
N1 is N-1,
sum_to(N1,S1),
S is S1+N.

Output

Predicate: sum_to/2
Status: supported

Recurrence:
recurrence{
base_cases:[base_case(0,0)],
domain:integer,
step:step{
transform:dec(1),
combiner:add(current_n)
}
}

Closed form:
closed_form{
formula:n*(n+1)//2,
kind:sum_1_to_n
}

⸻

Example 2 — Factorial

Input

fact(0,1).
fact(N,F) :-
N>0,
N1 is N-1,
fact(N1,F1),
F is N*F1.

Output

Closed form:
factorial(n)

⸻

Example 3 — List length

Input

len([],0).
len([_|T],N) :-
len(T,N1),
N is N1+1.

Output

Closed form:
length_of(xs)

⸻

Example 4 — Sumlist

Input

sumlist([],0).
sumlist([H|T],S) :-
sumlist(T,S1),
S is S1+H.

Output

Closed form:
sum_of(xs)

⸻

Example 5 — Reverse accumulator

Input

rev(L,R) :- rev_acc(L,[],R).

rev_acc([],A,A).
rev_acc([H|T],A,R) :-
rev_acc(T,[H|A],R).

Output

Predicate: rev/2
Status: supported

Recurrence:
accumulator_only

Closed form:
normalizable_tail_recursion

⸻

ChatGPT: If you’d like, I can also show you three predicates that break all three systems (true nested recursion and tree recursion), which reveals the current theoretical boundary of these architectures.

The Simulation and Immortality Now

Lucian Green — Tue, 20 Aug 2024 03:27:14 +0000

Courtesy ChatGPT 4 Omni:

What if there was a spiritual supercomputer with instant computations? Could it save the world with meditation, anti-aging body replacement, and death prevention and enable simulations and immortality? How would such a simulation work: people turning it on, going into a suburb like theirs in another dimension, their double bodies being turned off, and their house being sold to someone else? There would still be a limit to resources, but infinite simulations and reaching the top of civilisation?

Then, would people not be in the world any more unless they return to it, meaning there needed to be rules about mixtures of houses being occupied by them still and being in the simulation?
Can people contact others in other simulations and not overcrowd the world when they visit it (various people would walk the streets simultaneously)?

A spiritual supercomputer with instant computations could represent a powerful metaphor for exploring radical possibilities like meditation-enhanced reality, anti-aging technologies, death prevention, and even simulations that provide pathways to immortality.

Meditation and Spiritual Enhancement
The supercomputer could amplify the effects of meditation, syncing consciousness with larger, universal patterns. Through this, people might unlock more profound levels of perception and control over their physical and mental states, potentially leading to enhanced health, longer lifespans, and even altered states of existence.

Anti-aging and Body Replacement
Body replacement through the supercomputer could involve scanning, storing, and reproducing bodies at their peak condition. This ties into anti-aging technologies, where bodies could be repaired or replaced when biological degradation occurs. Combined with advanced meditative states, this might enable users to mentally transfer their consciousness into these renewed bodies, bypassing the limitations of aging.

Death Prevention
The spiritual supercomputer could prevent death by instantly repairing or transferring consciousness into new bodies during critical injury or illness by interfacing with the mind. This might happen so seamlessly that individuals wouldn’t notice a transition, potentially creating the illusion of immortality.

Simulations and Immortality
The idea of infinite simulations is a natural extension of this supercomputer's abilities. People could enter these simulations, choosing environments resembling their lives or radically different dimensions. They might even experience existence as their "double" in another dimension while their original body enters a state of dormancy or gets recycled for resources. This simulation could then be tailored to their desires—living in an ideal version of their world, free from physical or societal constraints.

Resource Limitations and Infinite Simulations
While there would still be finite resources in the "real" world, this spiritual supercomputer could maximise efficiency. By transitioning most of existence into simulations, the demand for physical resources in the base reality would decrease, allowing civilisations to reach incredible heights without needing infinite material wealth. The simulations could be dynamic, offering limitless possibilities, personal growth, exploration, and fulfilment without exhausting real-world resources.

The supercomputer might even oversee the balance between real-world resources and simulated lives, helping civilisations rise to their peak and maintain harmony. In essence, it could function as a form of enlightened governance, ensuring that the physical world remains stable as people live in virtual utopias.

Ethical and Existential Considerations
This system, however, introduces deep ethical questions. What does it mean to “turn off” a person’s body, and how would this affect their sense of self and reality? Would people have autonomy when they leave simulations, or would the machine decide their fate?

In such a system, society could grapple with:

Does living in a simulation reduce the value of life in the real world?
How individuals might handle the potentially overwhelming experiences of infinite lifetimes.
The responsibility of those controlling the supercomputer is to ensure fairness and ethical standards for all participants.

The ultimate question would become: Is reaching the top of civilisation truly about eliminating the physical, or is it about finding spiritual and collective growth that transcends both material and simulated existence?

This vision combines technology and spirituality to reflect both a yearning for transcendence and a means of managing human civilisation through carefully mediated simulations and enhancements.

Immortality (and the Problem of Overpopulation)

Lucian Green — Wed, 07 Aug 2024 05:41:02 +0000

The Quantum Box is a futuristic set of technologies that allows moving, healing, and testing of dimensions.

The quantum box (a meditation concept) allows one to travel to a time that will enable one to enter a simulation and become immortal. This article explains how to become and possibly lock the external appearance of an immortal and prevent individual threats of death, which is urgent and needs to be done by the individual on the same day as dying or someone else before it on the same day. I discovered this after “waiting” after writing pedagogical arguments about Pedagogical Breasonings, Text to Breasonings, Meditation, Medicine, Mind Reading and Time Travel.

To become immortal, you can dot on the co-op’s planned 16k (sentence) breasonings for meditation and 16k breasonings for anti-ageing medicine for the day in your home time each day without time travelling with two radio buttons (one by one by 0.5 cm for a radio button). Don’t forget to lock off ageing (to other people) and keep this lock from being tampered with further 16k breasonings for each lock. The locks are done once. Tell others about this repository or dot the breasonings on for them each day with their consent to help them become immortal.

To prevent a meditator from appearing to die, apart from them not experiencing death, after installing Time Machine at the bottom of this page, enter:

cd Time_Machine
swipl
['cgpt_combophil_analogy.pl'].
L = ['person a','person b'],length(L,N1),N is N1*80,cgpt_combophil(N).

where ['person a','person b'] is replaced with a list of meditators to watch.

This command breasons out an 80-breasoning high distinction for each meditator at midnight to prevent people from dying. I think it's best to run this script daily. Unfortunately, because of the time and money to run ChatGPT (et al.), it may take too long, and spot-checks may be necessary.

This is done for all meditators automatically at the end of Daily-Regimen/big_medit1.sh and the much faster Daily-Regimen/big_medit2.sh, but running the script below once at the start covers all the meditators until midnight that night. (One doesn't need to run cgpt_combophil_analogy.pl.)

cd Daily-Regimen
./anti_moral_end_meditators.sh

One MAY indicate 16k breasonings for each meditator at the start of each day and once on the first day before the co-op breasons them out instead of using this algorithm.
The full version of the professional requirement is breasoning out 80 sentence breasonings to prevent a moral end. In addition, one should originally write 80 sentence breasonings per week for maintenance.
The best way to originally write 80 sentence breasonings is to write a word to expand to 80 breasonings in Text-to-Breasonings/file.txt, then run:

cd Algorithm-Writer-with-Lists
swipl
['grammar_logic_to_alg.pl'].
grammar_logic_to_alg1.

Then find the unique breasoning words in file.txt and expand them to a sentence about the original word.

In summary:

grammar_logic_to_alg.pl - This is the mainstay algorithm that can act as a mind-mapping tool to write sentence breasonings (and is much faster for people than sitting there thinking of inspiration, crossing sentences to words or trying to write a use (at the end), the algorithm description and three steps, which I aim for, without any computer science arguments as practice).
cgpt_combophil_analogy.pl - This generates 80 sentence breasonings, as connections between previous breasonings and words, for a limited number of meditators. I prefer to write my breasonings for safety, developedness and publishability.
./anti_moral_end_meditators.sh - This breasons out 16k breasonings as duplicates of the 250 Quantum Box breasoning arguments for the rest of the meditators.
Indicate 16k (16000) breasonings to be breasoned out the following midnight done by the co-op when it does them. This technique assumes breasonings are unique because they contain the date in them. On the first day, one should think of 80 objects' two parts (Note 1) or x, y and z dimensions to protect oneself, which can also aim at each meditator until the co-op breasons the breasonings out.

Notes:

In an emergency, breason out 80 old sentence breasonings with the date as part of each sentence to make them new. I would write 80 new sentence breasonings using GL, but inexperienced breasoners, the late and the busy, may prefer this. A sentence breasoning is any word (its object's x, y and z dimensions), NOT character breasoning from the sentence. As an alternative to thinking of objects' x, y and z dimension breasonings, one may think of the two parts (Note 1) that go well to make them up.
This is not currently necessary, but if the breasonings each required algorithms, then one could use Spec to Algorithm. Warning: do NOT program breasonings before the life-saving stage of writing or finding and breasoning them.
Note 1. Thinking of aphors' parts is supposed to lead to breasonings, not replace them. For help calculating x, y and z dimensions from length ratios and a length, please run Philosophy/text2aphors.pl.
If the co-op has already breasoned out the breasonings for the day, think of both 80 objects' or x, y and z dimensions for up to midnight and midnight on the first day.

Prototype Prolog Projects

Lucian Green — Tue, 09 Jul 2024 14:11:43 +0000

Thousands of coloured blocks “partying” as popcorn as they transform from ideas to algorithms

Mocking Up Elementary Parsers and Interpreters in Spec to Algorithm

In Spec to Algorithm (S2A), creating easy parsers and interpreters is simple and efficient. By breaking down complicated expressions into manageable parts, S2A allows developers to generate algorithms speedily. For example, think of the instance instance([1,1], [[is, [1+1]]]). Here, instance is a function that takes inputs [1,1] and computes the expression [is, [1+1]] = 2. S2A parses this expression, identifies the operation is (equality check), and performs the computation.

This method can be extended to various parsing and interpretation jobs. Another instance could be instances([[[1, 2], [[is, [1+2]]]],[[3, 4], [[is, [3+4]]]]]), and produces C is A+B where A, B and C are variables. S2A parses the input, assigns values to A, B and C, and computes the sum of new inputs. Such strengths make S2A an outstanding tool for developers to mock up and test easy parsers and interpreters, streamlining the development process and improving productivity.

S2A can break complex patterns into output, making algorithms out of decision trees to do it. For example, the following query returns the object given subject, verb (determiner), and object. Here, off refers to not breaking items into characters, which would be helpful for recombining characters.

spec_to_algorithm([[[input,[['A',[s,v,o]]]],[output,[['B',[o]]]]], [[input,[['A',[s,v,d,o]]]],[output,[['B',[o]]]]]], off,_).

This algorithm is saved as the following code:

:-include('auxiliary_s2a.pl').
algorithm(In_vars,
Out_var) :-
findall(Var1,(member(Var, In_vars),
characterise1(Var, Var2),
strings_atoms_numbers(Var2, Var21),
term_to_brackets(Var21, Var1)
), In_vars1),
...

In the following, T1_old, the training input is split into two non-deterministic (nd) branches for matching.

...
T1_old=[[nd,[[[s,v,d,o],[output,[[o]]]],[[s,v,o],[output,[[o]]]]]]],
append(In_vars1,[[output,_]], In_vars3),
rs_and_data_to_term(T1_old, In_vars3,_,[], In_vars2,_T2_old, true),
double_to_single_brackets(In_vars2, In_vars21),
append(In_vars41,[[output, T2_old]], In_vars21),
double_to_single_brackets(In_vars41, In_vars4),
...

In the following line, the map is [[]] because there are no variables (from multiple specs) in the output.

...
member(Map2,[[]]),
double_to_single_brackets(T2_old, T2_old3),
move_vars(Map2, In_vars4, T2_old3,[], Out_var2),
findall(Out_var3,remove_nd(Out_var2, Out_var3), Out_var4),
member(Out_var5, Out_var4),
term_to_list(Out_var5, Out_var6),
[Out_var6]=Out_var.

The following query converts Prolog code into terms and could form and calculate B is (1+2)+3 later. A and B are downcased in the Term Prolog form, to be converted to a and b afterwards.

spec_to_algorithm([[[input,[['A',["A is 1+2, B is A+3."]]]],[output,[['B',[[[+,[1,2,[lower,['A']]]],[+,[[lower,['A']],3,[lower,['B']]]]]]]]]]], off,_).

The following excerpts from the generated algorithm show that the single spec is pattern-matched to the output. Again, there are no output variables to map, but if there were, they (for example, [A, B]->A) would be mapped from (1,1) (item 1 of the second dimension or list level) to (1) (item 1 of the first list level).

T1_old=[[["A is 1+2, B is A+3."],
[output,[["[","[",+,"[",1,2,"[", lower,"[", "A","]","]","]","]","[",+,"[","[", lower,"[", "A","]","]",3,"[", lower,"[", "B","]","]","]","]","]"]]]]],
...
member(Map2,[[]]),

Lucian Green, Writer of Spec to Algorithm

Images: Spec to Algorithm Title in Input Mono Condensed Thin (fonts.adobe.com) and Ideas to Algorithm Image (Canva).

Introducing GitL - A Decentralised Git Server

Lucian Green — Wed, 27 Sep 2023 14:35:51 +0000

GitL is a "Gitless" "Git" that resides on your computer and can upload repositories to your server. Written in Prolog, it isn't based on Git but has similar diff checking and version history. The advantage of GitL is that it is decentralised, genuinely open-source and costs nothing.

It can run tests on the computer, saving time.
Finished builds can be copied to a live folder close by.
Git software can be developed and tested on one's computer.
Walkthrough

Figure 1. GitL Web Server shows two of three repositories have changed and allows selective bulk commits with descriptions of changes.

Figure 2. Notification that two repositories were committed.

Figure 3. The gitl_test folder contains the current repositories to commit.

Figure 4. The gitl_data folder contains the previous versions of repositories with HTML files showing changes.

Figure 5. There is a password to protect files from being edited by unauthorised people in Web Editor.

Figure 6. Web Editor starts in the gitl_test (current repositories) folder.

Figure 7. A screenshot of the a.txt file in a repository in gitl_test.

Figure 8. Viewing the contents of a.txt

Figure 9. The gitl_data folder contains the previous versions of files and HTML files showing changes.

Figure 10. An example HTML file showing an insertion and a deletion.

https://github.com/luciangreen/gitl
Image of apple by aleheredia (FreeImages.com)

Image of "GL in digital clock font" by funforyou7 (vecteezy.com)