DEV Community: Lucian Green

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)

Yet Another Open Source CI/CD Tool

Lucian Green — Mon, 29 May 2023 10:32:14 +0000

Image of a female android by @deloan.

What is it?

In "DevOps" speak, CI means continuous integration of changes, and CD is continuous delivery and deployment, or placement of the best configuration of these changes back into the repository. If there are n changes, there are 2^n possible configurations of these changes, suggesting an upper limit of seven changes per run, meaning making few changes per time. The algorithm can be run on changes, allowing continuous code correctness.

Why I made it

I had recently written a List Prolog to Prolog pretty printer (which was its prerequisite). List Prolog is a variant of Prolog, a logic programming language in which programs are lists. I needed a way to check all the code before uploading it, preventing bugs and annoying installation problems.

Can it be used for other programming languages?

At its core is a diff by newline algorithm, so there's no reason why you couldn't modify it for programming languages other than Prolog. Every time it converts between Prolog and List Prolog, you would need to change it to convert between another language and List Prolog, which it procures tests from, checks for changed lines, and builds repositories.

Update: Lucian CI/CD can now process non-Prolog source files. These source files, coupled with tests, are integrated like Prolog.

Installing

Download and install SWI-Prolog for your machine at https://www.swi-prolog.org/build/.
Install LucianCICD using List Prolog Package Manager (LPPM):

git clone https://github.com/luciangreen/List-Prolog-Package-Manager.git
cd List-Prolog-Package-Manager
swipl
['lppm'].
lppm_install("luciangreen","luciancicd").
halt

Setting up

Create a folder "Github_lc" at the same level as your "GitHub" folder or the folder containing your repositories. This step is done by ['luciancicd.pl']. set_up_luciancicd.. NB. Please try the software with a folder other than "GitHub" such as "GitHub2" to see if it suits you.

NB. Edit the source and destination folder, such as "GitHub2", by modifying repositories_paths1//1 in luciancicd.pl. You can also edit folders to omit.

Before running, enter or modify tests in the source files in the repositories, for example:

% remove_and_find_item_number([a,b,c],2,c,N2).
% N2 = 2.
% remove_and_find_item_number([a,b,b,c],2,c,N2).
% N2 = 3.

Running

To load the algorithm, enter the following:

['luciancicd.pl'].

Run with luciancicd. - This tests repositories with changes. Run before committing changes.

What it does - Integrates changes into a possible new repository.

Figure 1. "Diff output. These are the changes combinations were taken from. Key: Insertion, Change and Deletion
[
[[n,comment],["File delimiter","../../Github_lc/a","a.pl"]],
[[n,comment],["% a(A)."]],
[[n,comment],["% A=1."]],
[[n,a],[1]],
[[n,comment],["% b(C)."]],
[[n,comment],["% C=1."]],
[[n,b],[1]],
[[n,c],[1]],
[[n,d],[1]],
Change: [["[[n,comment],[""%e(1).""]],"],' -> ',["[[n,e],[1]],"]]
[[n,f],[1]],".

Figure 1 shows the changes to the source files. The algorithm develops possible configurations from these changes and tests them.

What it does - Builds repositories using dependencies stored in the file.

The algorithm finds repositories depending and dependent on modified files and includes them in the possible builds. You can edit the dependencies in the dependencies registry file (below), and the behaviour of the built algorithm based on dependencies included by the source files should reflect the dependencies listed in the registry file used at installation.

Note: Dependencies are in List-Prolog-Package-Manager/lppm_registry.txt, in form [[User,Repository,Description,Dependencies], etc].
For example:
["luciangreen", "State-Machine-to-List-Prolog", "Converts State Saving Interpreter State Machines to List Prolog algorithms.", [ ["luciangreen","SSI"] ]].

There are more instructions about how to edit dependencies at https://github.com/luciangreen/List-Prolog-Package-Manager.

What it does: Tests to find the correct repository configuration and moves files into the folder.

The algorithm tests all files in all repositories connected with changed files. The first build configuration, which has the fewest possible changes, is stopped with.

Figure 2. The Prolog script that runs the tests.

#!/usr/bin/swipl -f -q

:- include('a.pl').
:- initialization(catch(main, Err, handle_error(Err))).

handle_error(_Err):-
    halt(1).
main :-
    d(A),A=1, nl,
    halt.
main :- halt(1).

Figure 2 shows the Prolog script, testcicd.pl, that loads the files and runs the tests collected. It runs with chmod +x testcicd.pl and swipl -f -q ./testcicd.pl.

One can read which tests failed in all combination builds, where, if a test fails, the algorithm doesn't move files into the repository.

NB. The algorithm moves finished files into the original repository, and the files in the repository swap places into ../private2/luciancicd-testing/.

What does it do, and does it work?

While one might think it would be simpler to make and test changes, this tool tries the usefulness of each changed line individually. One can ensure it works by entering tests to keep changes and make sure everything is stable.

Can it be integrated with ChatGPT?

Yes, the bottom-up Prolog version of Lucian CI/CD can be integrated with ChatGPT to complete or correct predicates with bugs. This would require the specs of all predicates in question and a ChatGPT API account.

Lucian Green

https://github.com/luciangreen/luciancicd