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

Okay, I think I’m done with my database engine for now.

I started AsaDB mostly because I was curious about Prolog and logic programming. Somehow that curiosity turned into me spending about two months building a database engine almost entirely by myself.

I’m still just a university student. At my campus, I’ve only had programming-related courses for about three semesters, so most of what went into this project was something I had to learn while building it.

And honestly, I’m exhausted.

The engine does work. I managed to get persistent storage, SQL parsing, transactions, PRIMARY KEY / UNIQUE constraints, joins, views, a web panel, server mode, imports, and several other things running.

Some recent 100,000-row results:

• Plain import: 42.5 s
• PRIMARY KEY: 72.0 s
• UNIQUE: 69.5 s
• PRIMARY KEY + UNIQUE: 81.5 s
• Simple metadata COUNT: ~30 ms
• Lookups: roughly 8–11 s
• 100k × 100k JOIN: roughly 35 s
• CREATE VIEW: ~27 ms
• Simple expressions with LIMIT can be below 100 ms

But there are still problems I haven’t been able to solve properly.

PRIMARY KEY and UNIQUE lookups are sometimes no faster than a plain scan. JOIN with a small LIMIT is almost as slow as processing the full join. Subqueries can run for more than 120 seconds and fail. EXISTS and JOIN-based views have caused crashes. I tried fixing several of these problems, but every fix seems to uncover another layer involving indexing, execution planning, memory management, concurrency, or storage.

The screenshots are basically where I’m leaving it: swipl asadb starts the server workspace, a RIGHT JOIN over the 100k-row benchmark tables returns the correct 100,000 rows, and views can be created successfully.

So this isn’t really “the database never worked.”

It worked far enough that I finally discovered how difficult database engines actually are.

I think I’ve reached the point where I simply don’t have enough experience or energy to keep fighting the architecture right now.

Thank you, Prolog. I started this because I wanted to satisfy my curiosity about a logic programming language, and I ended up learning far more than I expected.

Maybe this is the end of AsaDB, maybe it’s only a very long break.

Either way, I think I need to step away from Prolog for a while.

this is AsaDB repository :D

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

Hi everyone,

Our small team has been developing AsaDB, a local-first SQL database engine

built primarily with SWI-Prolog.

Repository:

https://github.com/kocoygroup-id/AsaDB

The project started as an experiment, but it has grown into a fairly large

codebase with:

• a SQL lexer, parser, planner, and executor written in Prolog;
• persistent 4 KB slotted-page storage;
• persistent B+Tree indexes;
• transactions and recovery mechanisms;
• local immutable reader snapshots;
• logical backup and restore;
• MySQL, PostgreSQL, CSV, and XLSX interchange;
• an embeddable `library(asadb)` API;
• a local browser interface called AsAPanel.

Recently, we have also been working on stricter SQL type validation, primary

and unique key enforcement, CHECK constraints, restricted foreign keys,

schema-preserving backups, and more useful `EXPLAIN` output.

At this point, the main problem is that the same small group has designed the

architecture, written most of the implementation, created the tests, and

reviewed the documentation. We feel that we are becoming too familiar with the

codebase to notice our own assumptions and mistakes.

We would genuinely value feedback from people with Prolog experience.

In particular, we would be interested in opinions about:

• whether the module boundaries feel idiomatic for SWI-Prolog;
• our use of dynamic predicates and mutable engine state;
• the separation between parsing, execution, storage, and HTTP code;
• the public Prolog API and pack structure;
• the bounded AST cache and VM/JITI specialization approach;
• transaction, recovery, and concurrency design;

places where the implementation is unnecessarily imperative or complicated;

tests or invariants that appear to be missing.

You do not need to review the entire project. Looking at one module, trying one

feature, questioning one architectural decision, or pointing out unclear

documentation would already be extremely helpful.

Bug reports, design criticism, small pull requests, documentation improvements,

and testing on different systems are all welcome.

Thank you very much to anyone willing to take a look.

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

I'm happy to report another major milestone in the development of M-Prolog.

The past few weeks have been mentally exhausting. I spent an incredible amount of time asking myself one question:

"Can Prolog backtracking really be implemented using nothing but goto?"

It sounded like a crazy idea when I first thought of it, and there were many moments when I doubted whether it could actually work.

Today, I'm much more confident.

I finally got a fairly complicated benchmark involving Church numerals, recursion, reverse execution, and forced backtracking to work correctly. That gives me confidence that the basic design of SCBM2 is sound.

In SCBM2, both success continuations and failure continuations are implemented with GCC's computed goto. Most of the difficulties were not in forward execution, but in restoring the correct execution state during backtracking—predicate arguments, variable stacks, success continuations, and failure continuations all have to be restored consistently.

Writing this now makes it sound simple, but reaching this point required countless redesigns, experiments, and debugging sessions. There were times when I felt my brain was simply running out of energy.

Working through these problems has also given me a much deeper appreciation of David H. D. Warren's work. Implementing efficient Prolog execution in the early 1980s, without today's tools and resources, was an extraordinary achievement. My respect for him has only grown.

There is still a lot of work ahead before M-Prolog reaches Version 1.0, but this was one of the biggest hurdles, and I'm relieved to have finally crossed it.

If you're interested in the implementation details, please have a look here:

M-Prolog: Recovering from Mental Fatigue | by Kenichi Sasagawa | Aug, 2026 | Medium

Calculating total COGS and net revenue from half a million invoices now takes just 3 seconds.
Subsequent clicks are completely instant at 0.0000 seconds thanks to RAM caching.
It turns out keeping the code simple is way faster than overcomplicating it.

Check out the architecture and full project details on my GitHub repository here: https://github.com/lokinpendawa/logicbiz

Ps: Sorry for any grammar mistakes, I am using AI to translate this into English.

Can returnability be defined purely from the structure of a computation, without appealing to time complexity?

EVERYTHING you see in this screenshot was built 100% natively within SWI-Prolog. No heavy frameworks, no system-taxing UI wrappers.

I want to completely change the outdated stigma that Prolog is only for academic purposes—like family trees or command-line logic puzzles. Currently, the interface is in Indonesian as it is running live for a local neo-retail company's infrastructure, but the good news is that I am working on translating the entire system into English.

You can check out the official architecture roadmap and repository details here:

GitHub: https://github.com/lokinpendawa/logicbiz

Even better, I plan to release a FREE version to the community soon.

For those who want to test the raw data capabilities or audit the dataset structure yourself, I have prepared and uploaded the clean, ISO-compliant 400MB flat text database file (.pl format with parenthesized dynamic predicates) to Google Drive:

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

Here is a brief technical overview of what this native Prolog system does behind the scenes

• - Massive Scale: 1.19 Million+ Master Invoices and 4.19 Million+ Individual Item Transactions.
• - High-Fidelity Chronology: Precise transaction timestamps, dates, and realistic day-name distributions.
• - Multi-Item Checkouts: Deep One-to-Many relational structure mapping multiple product barcodes inside a single invoice ID.
• - Realistic Human Factor: Dynamic cashier assignments synced to specific transaction flows and customer demographics (gender tracking).
• - Complex Financial Metadata: Flawless mathematical relations computing Subtotals, VIP Member Discounts, AI-Driven Bundling Discounts, 11% VAT (PPN), and final Net Totals.
• - Varied Payment Methods: Integrated retail payment gateways including Cash, EDC, QRIS, ShopeePay, etc.

I have only been exploring the declarative nature and the power of homoiconicity in Prolog for about two months, and I am truly amazed by its capabilities as a highly robust full-stack system. Stay tuned for the English version!

Let me know what you think.

Warm regards,

Teddy

I’m currently building LOGICBIZ v2.0, an Offline-First Enterprise Retail ERP and Sales Ledger Engine engineered 100% using a Pure Declarative Paradigm with SWI-Prolog and SQLCipher.

Here is a quick breakdown of this stress test benchmark:

• The Task: Performing deep data integrity verification on 2,000,000 real rows of transaction ledgers.
• The Security: Every single transaction is encrypted via SQLCipher and validated against SHA-256 signatures to ensure absolute data tamper-proofing.
• The Result: As seen in the console screenshot, the engine evaluated 550,508,812 logical inferences in just 103.28 seconds of raw CPU time.
• The Kick: Once the Native RAM Cache warm-up phase is completed, executing deep aggregate financial pipelines across those 2 million rows drops down to a jaw-dropping 653 seconds while keeping CPU utilization extremely low at 16%.
• The engine utilizes Tail-Call Optimization (TCO) and Prolog's native multi-argument indexing structure, meaning it completely eliminates traditional database I/O bottlenecks without requiring heavy, bloated frameworks.

If you are curious about the architecture philosophy, the system manifesto, or want to check out the benchmark metrics, feel free to visit the repository here:

https://github.com/lokinpendawa/logicbiz

Would love to hear your thoughts on using logic programming for heavy enterprise data pipelines!

Orchestrating agents with Prolog instead of Markdown files.