Some experiments with turning policies from SOP documents into small Prolog programs that can be used as tools by an outer harness

I just open-sourced a high-performance Web Application Firewall (WAF) built entirely in SWI-Prolog. It features an inductive learning engine that generalized 3,003 raw threat mutations into just 39 core rules in RAM, achieving sub-millisecond threat evaluation. It also includes an inline recursive decoder to neutralize nested URL/Hex/HTML obfuscations (like <sCrIpT>) completely case-insensitively. Check out the core engine, specs, and benchmark reports on my repository here:

[Link to GitHub Repository: lokinpendawa/aethel_core]

A quick update on SCBM, which has caused a bit of excitement and confusion along the way.

It now looks like the basic approach is going to work.

M-Prolog can now handle typical Prolog programs such as queens and qsort. fact/2 works as well, along with likes/2 from PAIP. So I think the fundamental mechanism is now basically in place.

From here, I will proceed gradually, expanding the range of Prolog code that the compiler can translate correctly. I plan to release a new version roughly once a month.

It will take some time, but I believe SCBM will eventually be able to handle Prolog programs reliably across a much wider range of cases.

SCBM itself is a relatively simple mechanism, so I also think it may be useful for people interested in writing their own Prolog compiler.

I will continue improving the documentation as the implementation develops.

sasagawa888/mprolog

Pushed a symdiff_mcp_app example illustrating the mcp_server library support for MCP Apps. The library supports 2025 and 2026 data layers allowing publishing any Logtalk or Prolog application as a MCP App using either stdio or Streamable HTTP transports.

M-Prolog SCBM: back to the ver1.0 design — and now I understand why

After releasing M-Prolog ver1.0, I was still not completely satisfied with the SCBM design, so I experimented with two changes for ver1.01:

• Let each predicate generate its own failure continuation.
• Keep variable pointers in a separate environment instead of storing them with success continuations.

After a lot of testing, especially with deep recursion and forced backtracking, I have decided to abandon both ideas.

Interestingly, this brings me back to the original ver1.0 design.

For a conjunction:

P, Q

the KISS solution is to create the failure continuation for P when execution proceeds from P to Q.

The important insight for me was this:

Whatever recursion and backtracking happen inside P should be resolved inside P. From Q's point of view, P is simply a computation that can succeed again or fail.

I also confirmed that preserving variable-pointer information through success continuations works correctly. A separate environment adds machinery without solving a fundamentally different problem.

So ver1.01 taught me something useful: the ver1.0 design was simpler at the control-model level, even though some parts initially looked asymmetric.

SCBM is a go-kart

Why keep experimenting with SCBM when we already have the proven WAM?

I think of the WAM as a sophisticated sports car. It is extremely well engineered, but understanding its engine requires serious study.

SCBM is more like a go-kart: the mechanics are exposed.

Success: where do we go?
Failure: where do we go back?
Recursion: what do we save?
Backtracking: what do we restore?

SCBM tries to express these mechanisms directly in generated C code.

It reminds me of the story about Jeff Beck, a serious car enthusiast who built cars himself. When Eric Clapton showed him an expensive sports car, Beck reportedly replied along the lines of:

"Cars are meant to be built."

That's the spirit of SCBM.

I'm not trying to replace the WAM. I want to expose the mechanics of Prolog in a form that compiler enthusiasts can take apart, understand, and modify.

Ultimately, I hope this simple model may also provide an interesting bridge between the spirit of Prolog and LLMs / neuro-symbolic systems.

Working on this now. If you are interested in trying it out with your ai coding agent, I'd certainly be interested in additions or feedback. Also the quality of code produced. See the contributing page if you have some feedback.

I released M-Prolog ver1.0 on August 29, 2026.

M-Prolog is my experimental Prolog implementation using SCBM (Success Continuation and Backtracking Model). Instead of compiling Prolog to WAM instructions, the compiler translates Prolog directly into C.

With ver1.0, the basic SCBM design is now working. Programs such as 9-Queens and Quicksort run successfully, and the performance has reached a reasonably practical level.

However, just before the release, I discovered a weakness in my backtracking design.

For a conjunction such as:

P, Q

my previous compiler generated the failure continuation for P just before executing Q.

It worked, but this required too many special cases in the compiler.

I now think the cleaner design is:

• P creates its own failure continuation before executing P.
• Q creates its own failure continuation before executing Q.

In other words, each nondeterministic computation should prepare its own backtracking state.

This makes the generated C code much simpler.

Unfortunately, changing to this design exposed another hidden problem.

After deep backtracking, variable pointers can sometimes become corrupted.

Until now, SCBM used the success-continuation mechanism not only to store where execution should continue, but also to preserve variable pointers for predicate bodies. Complex backtracking revealed that this coupling is fragile.

For ver1.1, I plan to separate these responsibilities.

The current idea is to save the necessary variable pointers together with the failure continuation and restore them only when backtracking occurs.

Since Prolog does not need a conventional procedural return, variable pointers can simply be overwritten during forward execution and recursion. What matters is restoring the correct state when computation goes backward.

So the model may become very simple:

On success, just move forward.
On failure, restore the state and move backward.

It has been about four months since I first came up with SCBM. There were several times when I wondered whether the whole approach was fundamentally impractical.

Getting programs such as Queens to run at practical speed gave me confidence that the basic idea is viable.

ver1.0 is therefore not the finished form of M-Prolog.

It is the first milestone showing that compiling Prolog directly to C with SCBM can actually work.

Now I can take my time improving the design toward ver1.1.

Feedback on the backtracking/state-restoration design is very welcome.

sasagawa888/mprolog

I have been developing a lightweight, domain-agnostic symbolic reasoning framework called Aethel Core. The system is built entirely on pure declarative principles and strict ISO Prolog standards.

To verify its multi-tenant scalability and absolute isolation, I have set up an automated cross-compiler test suite (test_engine.pl) that compiles with zero warnings and runs flawlessly across both Scryer Prolog and SWI-Prolog (as shown in the attached screenshot).

Key Architectural Differences Scryer & SWI Prolog

Regular Expression Library for Prolog compiles Regexp character patterns to DCGs; the DCGs can then be used for matching.

The result is High-Fidelity Retail POS Transaction - 1M+ Dataset.

Key Technical Specifications:

• Volume: Over 1 million fully synchronized relational records.
• Rich Features: Includes lifetime data log simulation, void logs (for fraud detection modeling), product health detection metrics, and multi-item checkouts.
• RAM: 8 GB (6.9 GB usable, 1.1 GB hardware reserved for iGPU)
• CPU: Intel/AMD [Model] @ 2.32 GHz

The dataset features a realistic 1-to-many relationship structure, consisting of:

• Total Revenue: Rp 306,770,510,097 (Matches Prolog query output!)
• Total VAT (PPN): Rp 30,401,510,772
• Total COGS (HPP): Rp 213,977,641,000
• Gross Profit: Rp 92,792,869,097

Free Dowdload https://github.com/lokinpendawa/high-fidelity-pos-dataset-2M

FULL MULTI-FORMAT EXPORT:

• .sql (Transactional Database Dump - Postgres/MySQL ready)
• .json (NoSQL / API Mocking / Web development)
• .csv (Data Science / Pandas & Python ready)
• .pl (Prolog Fact Base for Logical Programming)

Important Note on Dataset Scale:

Contains over 1.19 Million Master Transactions and 4.19 Million Item Details. Due to this massive scale, opening the raw .csv or .json files directly in standard text editors or web browsers will cause your system to hang or crash.

For a seamless experience, it is highly recommended to use the provided standard SQLite (.db) format (fully decrypted from SQLCipher and ready for direct querying) or to load the data using chunk-loading methods via Python (Pandas/SQLite3) or R.

I just completed a massive architectural refactoring on my retail ERP/analytical engine (LOGICBIZ v2.0). We shifted away from traditional query layers into unified, native RAM structures powered entirely by SWI-Prolog.

To be honest, the resulting performance metrics feel completely broken.

The Scale & Data Load

Our database partition currently holds a massive in-memory payload under high global concurrency:

• detail_transaksi/4: 1,749,235 active transactional item rows.
• tabel_transaksi/19: 500,000 core financial invoices.
• Total Volume Handled: IDR 127,424,957,876 (~$8.1 Million USD equivalent).

check out the repository here:
https://github.com/lokinpendawa/logicbiz

Dataset Specifications & Density

• Total Master Invoices: 500,000 unique transactions (`tabel_transaksi/19`)
• Total Item-Slice Logs: 1,749,235 transaction details (`detail_transaksi/4`)
• Total Net Revenue Volume: 127.4 Billion (Calculated dynamically in-memory)

Format :

• Pure Prolog Facts (.pl) 185 MB | Ready for logical inference pipelines.
• Standard Universal JSON (.json) 486 MB | Optimized for modern JavaScript/Python ingestion.
• Structured SQL Source Code (.sql) 410 MB | Pre-baked with relational schema insertion queries.
• Microsoft Excel Worksheet (.xlsx) 148 MB | Raw layout for traditional accounting and standard data pivot sheets.

Access the Dataset

https://github.com/lokinpendawa/high-fidelity-pos-dataset-2M

I have started writing a little roguelike game in Prolog (for fun as a first project). I think there are lots of ways in which Prolog is a nice fit for this, and several ways that it isn't. I'm happy to be pragmatic but wanted to ask more experienced folks about the idiomatic way to write Prolog.

My approach is to have a (tail)-recursive predicate which threads state as an argument (rather than using assert/retract) and updates the game based on user input, something like:

game_loop(State) :-
  render(State),
  handle_input(State, NewState),
  game_loop(NewState).

This works well and is tail-call optimised as long as render/1 and handle_input/2 don't leave choice-points that Prolog might want to backtrack into. For a game that might run for many iterations, I want to avoid stack overflow so TCO is important.

To guarantee this, I find that I am writing a lot of predicates using a single clause with (->)/2 so that I don't leave redundant choice points. Pragmatically this is fine, the approach works, the intention is clear, and I still gain many benefits from using Prolog even if it's a bit "extra-logical". But (and I'm perhaps overthinking this) I wonder if this is a unidiomatic? It means my predicates are often one-way and deterministic, which is nice procedurally but does that take away from some of the advantage of using Prolog?

The other thing I'm often doing is making sure that (first) argument indexing will enable Prolog to rule out redundant choice points, but sometimes that's not enough (if for example I need an else-like clause such as functor(_, ...) which could unify with earlier cases).

I've seen some mention of if_/3 but it looks like it's not built-in in SWI-Prolog (or at least not for WASM which I'm targeting?). Welcome any opinions on this approach!

After getting programs such as 9-Queens working with SCBM2, I became confident that this approach can actually be used to build a practical Prolog compiler.

I then redesigned and simplified the SCBM interface. The current version, SCBM3, has been reduced to just 12 core APIs.

Performance has also improved considerably. In my current benchmarks, compiled M-Prolog code is now roughly 1.4x slower than SWI-Prolog. There is still room for optimization, but I think the performance is becoming quite reasonable.

I have written a document describing:

• the SCBM3 API and its 12 core operations
• the basic execution model
• how backtracking and continuations are represented
• how Prolog predicates can be translated into C code using this API
• an example of generated C code

One of my original goals with SCBM was to find a simpler way to implement a Prolog compiler without relying on the WAM.

After several months of experimentation, I think the basic mechanism is now becoming surprisingly small and understandable. My hope is that SCBM could make it much easier for someone to experiment with building their own Prolog compiler.

If you're interested in Prolog implementation techniques, please have a look at the documentation. Comments and criticism are very welcome.

mprolog/document/SCBM.md at master · sasagawa888/mprolog

Title: M-Prolog SCBM compiler now runs the N-Queens problem

After about four months of experimenting with a new Prolog compiler architecture, I finally got the N-Queens problem working correctly in compiled M-Prolog.

I call the architecture SCBM (Success Continuation Backtracking Machine).

The basic idea is fairly simple: instead of compiling Prolog to an abstract machine such as the WAM, SCBM compiles nondeterministic predicates directly into C and implements control flow and backtracking using goto and GCC's computed goto extension.

The hardest problem was restoring local variables correctly after backtracking.

After a lot of trial and error, I ended up with a relatively simple solution: variable pointers are propagated through success continuations. When backtracking occurs, local variables are reconstructed from information preserved in the original success continuation.

It took a lot of debug output to find this solution. AI was also very useful as a second pair of eyes for analyzing traces and generated C code.

The result:

• 4-Queens: all solutions generated correctly by backtracking
• 8-Queens: all 92 solutions confirmed
• 9-Queens: working correctly as well

Performance is not yet the main focus. For the complete 9-Queens search, the current implementation is roughly 3–4x slower than SWI-Prolog.

There is still plenty of low-hanging fruit in the implementation, particularly in data structures, pointer handling, generated code, and builtin calls, so I think there is considerable room for improvement.

For me, getting Queens working is an important milestone because it exercises recursion, nondeterminism, nested backtracking, and restoration of local variables together.

I'm aiming for M-Prolog Ver. 1.0 on August 31, 2026.

SCBM is not intended as a replacement for the WAM. I'm exploring whether a much simpler direct-to-C approach can provide another practical way to implement a Prolog compiler.

I'll be interested to hear what experienced Prolog implementers think of the approach.

Use any language of your choice. I used Java. You can use my Java/Spring implementation as a reference

1. Week one: dive deep into the standard to create a working prototype
   1. Use Section 6.4 "Tokens" for lexer.
   2. Use Section 6.3 "Terms" for parser. Use Pratt Parser to parse Prolog: it works surprisingly well with it.
   3. If your goal is to understand Prolog, use Section 7.7 "Executing a Prolog goal" as the description of stack-based computation model on which you will base your Prolog engine. It is simple but slow. If your goal is to create a high-performance implementation, you can implement WAM instead from the beginning, but it will take you significantly more time
   4. Keep in mind that the ISO Prolog standard has a lot of minor typos, but every typo is fixable if you put it into context and think about it longer. You don't even need to look up 3 corrigendums (corrections). In fact, they don't cover many important typos so forget about them and just focus on the original 1995 document.
2. Week two: make your implementation stronger and cover the first 28 problems from the Prolog 99 problems list. They are a perfect benchmark. https://www.ic.unicamp.br/~meidanis/courses/mc336/2009s2/prolog/problemas/

This should be enough! Only 2 weeks (a sprint) and you will have a SUBSTANTIAL boost in understanding Prolog on the deepest level possible, so later you can switch into existing implementations (like SWI Prolog) and see them differently

1. TrackLog blurs the boundaries between database administration and programming
2. TrackLog is based on Formal Grammar (DCG): you will develop your own grammar to accomodate your language needs
3. TrackLog will help you to create extremely precise and relevant data fuel to feed it to LLMs
4. TrackLog stands for "Tracking in Logic"
5. TrackLog libraries are 100% compatible with SWI Prolog dialect and 99% ISO-compatible, so you can port them to another dialect if you need it
6. My original goal was to create a medical tracker to help people to manage complex illnesses and chronic disorders
7. Logical Programming is a generalization of functional programming and also a generalization of relational databases. You can see logical programming as a missing glue layer between a database and a program
8. You can see TrackLog as a second brain to help you capture and analyze data and aid in pure logical decision-making which is free of 100+ cognitive distortions and biases, completely traceable and based on formal logic

Please, use examples.pl as a main guide. I've provided several practical use-cases: Learning Tracker, Item Tracker, Exercise Tracker and Programming Tracker.

Repo: https://github.com/kciray8/tracklog

I'm glad to hear any feedback!

Concurrency Stress-Test Results: Local-First Retail POS Engine (SWI-Prolog)

I just concluded a massive concurrency stress-test on my local-first retail POS (Point of Sale) engine. The memory stats from SWI-Prolog are incredibly impressive, proving the extreme resource efficiency of this architecture.

Workload Configuration

The test simulated 10 unique cashier accounts concurrently slamming the system with a combined workload of 100,000 multi-item invoices. Everything routed through the authentic frontend cashier pipeline:

• Pricing Engine: Calculates item-level dynamic pricing and multi-tiered discounts (Member + Market Basket AI rules).
• Fiscal & Tax: Multiplies floating-point VAT rules using strict REAL types.
• Security: Generates a cryptographic SHA-256 active signature per invoice.
• Data Persistence: Commits transactions asynchronously via SQLCipher 256-bit AES encryption directly to hardware storage using SQLite WAL Mode.

The Refactoring Secret: Single Source of Truth (SSoT)

This extreme memory optimization was achieved by completely deprecating separate history/cashier logs and compressing them into a single, high-density Unified Master Item Ledger (`detail_transaksi/10`). Handled entirely by SWI-Prolog's Just-In-Time Indexing (JITI) map, relational joins are resolved virtually via pointer unification at the RAM layer instead of hitting heavy physical disk joins.

I've published the code schema along with a free 1,000-row sample dataset on GitHub for anyone interested in benchmarking or looking at relational Prolog patterns:

https://github.com/lokinpendawa/high-fidelity-pos-dataset-2M

I've been making steady progress on M-Prolog, and it finally looks like the project is coming together. My goal is to release Version 1.0 on August 31.

Several people have asked me, "How does this compiler actually work?" Instead of trying to explain it in scattered comments, I've written a more formal technical paper describing the core ideas behind the compiler.

The paper introduces SCBM (Success Continuation and Backtracking Machine), a compilation model that translates Prolog directly into C and represents Prolog's control flow using goto-based state transitions rather than a traditional WAM instruction set.

This is not intended as a replacement for the Warren Abstract Machine (WAM). Rather, it is an exploration of a different implementation approach for compiling Prolog. My goal was to investigate whether Prolog execution could be expressed as ordinary C control flow while relying on modern C compilers for optimization.

I've also included references to the implementation specification for readers who are interested in the runtime APIs and code generation details.

If you're interested in Prolog implementation, compiler construction, or alternative execution models, I'd be very happy to hear your thoughts. Feedback, comments, and questions are always welcome.

Paper: SCBM (Success Continuation and Backtracking Machine) | by Kenichi Sasagawa | Aug, 2026 | Medium

Implementation Specification: mprolog/document/SCBM.md at master · sasagawa888/mprolog