I'm pleased to announce the release of SCBM-Prolog version 1.50.

Since my previous report, I have completed the implementation of several important language features, including cut (!), call/1, negation as failure (not/1), and disjunction (;).

The compiler can also handle Japanese predicate names, and various tests involving recursion, unification, and backtracking have been successful.

SCBM (Sasagawa Continuation Backtracking Model) is an alternative Prolog execution model that does not use the conventional WAM architecture.

Its central idea is to represent a proof tree as a linear, doubly linked proof sequence, integrating success and failure continuations into a unified execution mechanism.

With version 1.50, I believe I have demonstrated that this approach is not merely a theoretical idea, but has the potential to serve as the foundation of a practical Prolog implementation.

Of course, further testing, refinement, and performance evaluation are still necessary. However, the major technical challenges have now been addressed, and development has progressed considerably faster than I originally expected.

My next step is to focus on documentation and a technical paper explaining the SCBM model, its underlying principles, implementation techniques, and experimental results.

I hope this work will offer another perspective on Prolog implementation and perhaps encourage students and independent developers to explore alternative execution models.

The project is available on GitHub:

https://github.com/sasagawa888/scbm

Comments, questions, and technical feedback are always welcome.

I've just released SCBM-Prolog Ver 1.29.

Development has been progressing much more smoothly than I originally expected. There were many difficult challenges along the way, especially in implementing backtracking, restoring proof sequences, and handling recursive predicates.

However, the core execution mechanism is now working reliably, and the remaining tasks are becoming much clearer.

As I mentioned in the release notes:

SCBM-Prolog started with a simple question:

"Why does Prolog work?"

I wanted to express Prolog's execution mechanism using the simplest possible data structures and algorithms.

By representing proof trees as linear proof sequences using doubly linked lists, SCBM provides a unified way to handle execution, success, failure, and backtracking.

The current implementation successfully handles recursive predicates, permutation generation, prime number enumeration, and the 9 Queens problem, including all 352 solutions.

Performance has also reached approximately 10 MLIPS on my Ryzen/Linux system.

The remaining tasks include refining the cut implementation, implementing call/1, not/1, and disjunction, adding Unicode support, and completing the documentation.

There is still work to do, but the most difficult part—the fundamental execution mechanism—appears to be behind me.

At this pace, I believe SCBM-Prolog will reach its first complete version in the near future.

It has been an exciting journey, and I'm looking forward to seeing how far this simple approach can go.

GitHub: https://github.com/sasagawa888/scbm

I've been developing SCBM-Prolog, an experimental Prolog compiler based on my own execution architecture.

Recently, SCBM reached an important milestone: it can now handle recursive predicates, complex backtracking, permutations, and the 9-queens problem.

My original goal was to develop an alternative to the Warren Abstract Machine (WAM), hopefully achieving comparable performance someday.

But I've recently discovered another goal.

I want to make it possible for amateur programmers to build their own Prolog compiler.

I first encountered Prolog around 1980. At that time, running Prolog generally required access to a minicomputer.

I remember disassembling a Prolog interpreter written for the 6502 processor, trying desperately to understand how it worked. Unfortunately, I couldn't figure it out.

Nearly half a century later, I'm finally building my own Prolog system.

Recently, I watched a documentary about Tamiya, the famous Japanese plastic model manufacturer.

As a child, I loved building Tamiya models. Their parts fitted together beautifully, and their instruction manuals made even complicated machines accessible to children.

That gave me an idea:

Why not make SCBM-Prolog something like a Tamiya plastic model kit?

Instead of simply publishing source code, I could provide architectural diagrams, explanations, and step-by-step instructions so that programming enthusiasts could understand the system and build their own compiler.

One advantage of SCBM is that its execution model is based on a linear proof sequence represented by a doubly linked list. The generated C code corresponds relatively directly to this model.

I believe this could make the implementation easier to understand than a highly optimized WAM-based system.

Of course, SCBM is still experimental. There is much work ahead, including optimization, implementing cut, and expanding language support.

But I now have two goals:

• Develop an original Prolog execution architecture with competitive performance.

• Make Prolog compiler construction accessible and enjoyable for hobby programmers.

I've written a longer article about this idea on Medium:

SCBM-Prolog: Build Your Own Prolog System

SCBM-Prolog: Build Your Own Prolog System | by Kenichi Sasagawa | Nov, 2026 | Medium

I'm curious what other Prolog enthusiasts think.

Would a well-documented, build-your-own Prolog compiler be interesting to you?

After all, using a programming language is fun, but building one yourself can be even more rewarding.

I'd like to share some recent progress on my experimental Prolog compiler, SCBM-Prolog.

SCBM (Sasagawa Continuation Backtracking Model) is an alternative execution architecture to the traditional WAM. It represents Prolog execution as a linear proof sequence using a bidirectional list, rather than following the conventional WAM approach.

After nearly three months of struggling with the perm1 permutation problem, I finally solved the remaining backtracking issues.

The key was reconsidering how the system handles complete failure and restores the original predicate within the proof sequence.

With perm1 fully working, I moved on to the 9 Queens problem.

And it worked! All valid solutions were generated successfully.

The current benchmark for 9 Queens is:

• Execution time: 0.047630 seconds

• Performance: approximately 7.23 MLIPS

• Compiler: GCC with -O0 (no optimization)

There is still considerable room for improvement. My next target is 20 MLIPS.

These results suggest that the SCBM architecture can handle complex recursive backtracking and may provide a relatively simple and lightweight foundation for implementing a Prolog compiler.

Of course, this is still an experimental implementation. More testing, optimization, and language features are needed. In particular, the cut operator (!) has not yet been implemented.

I have written a more detailed development report on Medium:

SCBM-Prolog: Operation Orion and the Decisive Battle at Gamilas

SCBM-Prolog: Operation Orion and the Decisive Battle at Gamilas | by Kenichi Sasagawa | Nov, 2026 | Medium

The somewhat unusual title comes from Space Battleship Yamato, a classic Japanese science-fiction series. I've been treating the development process as a voyage through space, with each difficult bug representing another major battle. :)

The project is open source, and I welcome technical feedback, suggestions, and criticism.

sasagawa888/scbm: SCBM (Sasagawa Continuation Backtracking Model) is an experimental execution model for Prolog. It explores a simple alternative to the WAM, using explicit success and failure continuations and direct compilation to C.

The decisive battle is over. Now begins the journey home!

I've released SCBM-Prolog ver1.11, an experimental Prolog implementation based on a new execution model using a linear proof sequence represented by a doubly linked list.

I've been debugging the system using the likes/2 example from Peter Norvig's Paradigms of Artificial Intelligence Programming (PAIP).

The main challenge was handling backtracking after complete failure. When a predicate is replaced by its recursively expanded body, the original predicate must eventually be restored so that the remaining alternatives can be explored.

After fixing this restoration mechanism, SCBM-Prolog now produces all six expected solutions.

This is a small but important milestone. It suggests that the basic idea of executing compiled Prolog code through a dynamically reconstructed proof sequence may be viable.

I've written a short article explaining the problem and the solution:

SCBM-Prolog: Cat Successfully Captured — Heading Out of the Solar System

SCBM-Prolog: Cat Successfully Captured — Heading Out of the Solar System | by Kenichi Sasagawa | Nov, 2026 | Medium

The implementation is still experimental, and many issues remain. My next target is fact/2, which is not yet working correctly.

I'd be happy to hear any thoughts or suggestions from fellow Prolog enthusiasts, particularly about alternative approaches to backtracking and execution-state restoration.

sasagawa888/scbm: SCBM (Sasagawa Continuation Backtracking Model) is an experimental execution model for Prolog. It explores a simple alternative to the WAM, using explicit success and failure continuations and direct compilation to C.

This has been sitting in my head for over 6 months since the second lecture I had on Logic Programming where I was introduced to SWI-Prolog's `trace` predicate (I'm not sure if it exists in other implementations).

This is what the output of `?- sibling(sally, erica).` looks like with tracing on:

5 ?- trace.

true.

[trace] 5 ?- sibling(sally, erica).

Call: (12) sibling(sally, erica) ? creep

Call: (13) parent_child(_23350, sally) ? creep

Call: (14) father_child(_23350, sally) ? creep

Exit: (14) father_child(tom, sally) ? creep

Exit: (13) parent_child(tom, sally) ? creep

Call: (13) parent_child(tom, erica) ? creep

Call: (14) father_child(tom, erica) ? creep

Exit: (14) father_child(tom, erica) ? creep

Exit: (13) parent_child(tom, erica) ? creep

^ Call: (13) not(sally=erica) ? creep

^ Exit: (13) not(user:(sally=erica)) ? creep

Exit: (12) sibling(sally, erica) ? creep

My question: Can there be a program that, given *nothing more* than this trace, can figure out (synthesize, I suppose) a set of rules and facts which would yield this trace for the same query?

Further question: Since the first program would accept a single trace and output a single set of facts and rules, can there be a program which takes several of these outputs and generalizes them? So if we fed to this pipeline a representative enough sample of queries and traces of our program, we would be able to synthesize the program exactly?

Is this possible? Does it exist? Is this something that has been done before? Is there any research on it? (I'm sure someone much smarter than me has thought about it before, I'm surely not the only one who's thought of this)

I have released N-Prolog Ver 5.20.

During the development of SCBM-Prolog, I discovered some bugs related to unification in N-Prolog.

These bugs have been fixed in this release.

If you encounter any bugs or unexpected behavior, please let me know. Bug reports are always welcome.

Thank you for your continued interest in N-Prolog!

GitHub: https://github.com/sasagawa888/nprolog

After about six months of experimenting with SCBM-Prolog, I have decided to fundamentally redesign its execution model.

I am calling this new effort Project YAMATO.

In SCBM3, I used stacks to manage success and failure continuations. This worked reasonably well for ordinary execution, but repeated backtracking in recursive predicates caused serious problems. In particular, necessary success continuations could be lost.

I tried many approaches to solve this problem, but none was completely satisfactory.

So I decided to return to the original idea behind Prolog: SLD resolution itself.

The basic idea

Instead of managing continuations primarily through stacks, Project YAMATO will represent the proof process using a doubly linked list of predicate objects.

Each object will contain its execution state, including variable pointers, local stack information, argument counters, and a pointer to the corresponding C code label.

The execution model will be straightforward:

• Success: Follow the list forward and execute the next predicate object.

• Failure: Traverse backward to find an available choice point and perform backtracking.

• Recursion: Expand and replace recursive goals with new predicate objects, just as in SLD resolution.

• Execution: Use C's computed goto mechanism to avoid the overhead of repeated C function calls.

The main goal is to make the runtime structure correspond directly to the SLD proof process.

Why not the WAM?

The Warren Abstract Machine is an excellent execution model, but its internal architecture is considerably more complex than the original SLD resolution concept.

I want to explore a different approach.

If you understand SLD resolution, you should be able to understand the execution mechanism of Project YAMATO.

At the same time, I hope to achieve good performance by using direct jumps in C.

Of course, I do not yet know whether this approach will be competitive in speed. Linked-list operations and object creation have their own costs.

That is something I intend to investigate experimentally.

A one-year project

My first goal is to correctly execute recursive and nondeterministic programs such as perm1/2, including repeated and deeply nested backtracking.

The target completion date is October 2027.

Since my professional work will keep me busy, I intend to develop this gradually as a personal research project.

The name YAMATO comes from the Japanese science-fiction anime Space Battleship Yamato. In the story, the spaceship has one year to complete its mission and return to Earth with the Cosmo Cleaner.

I have given myself the same one-year deadline.

I have written a more detailed explanation of the design on Medium:

SCBM-Prolog: Project YAMATO — A New Execution Model for Fast SLD Resolution | by Kenichi Sasagawa | Oct, 2026 | Medium

I would be interested in hearing your thoughts, particularly about representing SLD proof states using a doubly linked list and the trade-offs involved in this approach.

Hopefully, I will return to Earth with the Cosmo Cleaner in October 2027!

I've been struggling with my experimental SCBM-Prolog implementation for several months now.

SCBM stands for Sasagawa Continuation Backtracking Model. It's my attempt to implement Prolog using explicit success and failure continuations, with goto-based control flow in C.

To be frank, there were times when I thought the whole approach was simply too complicated and that I should abandon it.

But after months of debugging, failed experiments, and redesigns, I feel I'm finally reaching a deeper understanding of the problem.

The key insight is surprisingly simple:

• Backtracking control is dynamic. It must return to the appropriate choice point according to the execution history.

• Variable identities must remain consistent. Within each clause invocation, the original variable pointers must be preserved.

• Recursion requires environment restoration. When execution returns from a recursive call through a success continuation, the caller's original variable pointers must be restored.

The third point was particularly important.

When backtracking occurs deep inside a recursive predicate, execution may eventually succeed and return through multiple success continuations. At each level, the corresponding variable environment must be restored.

I had overlooked this requirement and also introduced a bug in the propagation of variable pointers.

Looking back, these requirements seem quite natural. But it took me months of trial and error to understand their implications for my implementation.

I'm not claiming that I've solved everything yet. And I'm certainly not claiming that SCBM is superior to WAM or conventional Prolog implementations.

This is an experiment in exploring a different approach to Prolog execution, and also a personal intellectual challenge.

I originally set October 20 as my target date. There are only eight days left.

I was seriously considering abandoning SCBM and returning to a more conventional SLD-based implementation. But now that the underlying issues are becoming clearer, I've decided to keep pursuing the original idea a little longer.

Perhaps it will work. Perhaps I'll discover another fundamental problem.

Either way, these months have taught me far more about Prolog execution, recursion, variable environments, and backtracking than I expected.

I've written a more detailed explanation on Medium:

[Insert Medium article link here]SCBM-Prolog: Eight More Days — Let’s Keep Trying! | by Kenichi Sasagawa | Oct, 2026 | Medium

Eight more days. Let's see what happens!

He created so many wonderful handcrafted prolog exercises on Exercism, and I would like to say "thank you" to him and also ask several questions about the track.

I've sent a message to [email protected], but have no response. I've also tried to connect on LinkedIn, but unable to send a message there because of restriction for non-premium users.

I thought this was interesting

Rewriting and rejection are supposed to result in a large reduction of the search tree and produce an operational semantics that is more efficient than Prolog's resolution strategy.
...
ALF programs are compiled into instructions of an abstract machine, which is based on the Warren Abstract Machine (WAM) with several extensions to implement narrowing and rewriting.

So based on the WAM and theoretically more efficient? But then the link to what I guess is/was the main developers of this system is dead, and besides a couple miscellaneous articles can't really find too much info on it besides this manual from 1995.

Is this just a dead project? Anyone know if these rewrite/narrowing optimizations they're referring to have been built into the SWI or Scryer WAM?

It has been about six months since I first came up with the idea of SCBM-Prolog, a Prolog compiler based on an approach quite different from the WAM.

I have never been completely satisfied with SCBM4, which I have been working on recently. I keep looking for a simpler, clearer, and more efficient approach, and as a result, I have repeatedly built and tested different versions of the design.

In Japan, we have a series of holidays around this time known as Silver Week. I spent much of the holiday experimenting with SCBM again.

After all those experiments, I have finally begun to realize that SCBM3 — an approach I had previously abandoned — may actually be the most promising one.

At the time, I encountered a problem that I simply could not overcome, and I concluded that there must be something fundamentally wrong with the design itself. So I abandoned SCBM3.

Now I am beginning to think that conclusion was wrong.

More importantly, I am finally starting to understand why SCBM3 did not work correctly at the time.

So I am returning to it once again.

Six months after starting this project, I am still experimenting, debugging, abandoning ideas, returning to old ones, and improving SCBM-Prolog little by little.

Apparently, I still haven't learned how to give up. :-)

SCBM-Prolog: Cockroach Hunting. Before the long weekend, I came up with… | by Kenichi Sasagawa | Sep, 2026 | Medium

sasagawa888/scbm: SCBM (Sasagawa Continuation Backtracking Model) is an experimental execution model for Prolog. It explores a simple alternative to the WAM, using explicit success and failure continuations and direct compilation to C.

I've been building a mobile notebook app and the part this sub might care about is the Prolog kernel. It's the official swipl-wasm build of SWI-Prolog running inside an Android WebView, fully offline once installed. No server, no account.

What a Prolog cell does:

• Directives (:- ...) run silently, assert/retract/consult are executed and confirmed, and anything else is treated as a query and all solutions are enumerated (member(X,[a,b,c]). gives you three answers).

• A cell that mixes clause definitions and queries is split: the clauses are consulted as a source file, the queries run afterwards, so you can write a small program and its test query in one cell.

• Files are shared with the other kernels. Prolog's native open/3 and write/1 go to Emscripten's FS, which is mirrored into a shared virtual filesystem that Python, R, Bash and JS cells also see. So a Python cell can generate facts to /shared/data/facts.pl and the next Prolog cell consults them. Everything persists in IndexedDB.

• load_url('https://...', '/shared/lib/x.pl') fetches and consults a file, and a package format lets you bundle knowledge bases with a notebook.

• Notebooks import and export as .ipynb, so a Prolog notebook opens in Jupyter too (as a static document).

Known limits: it's one toplevel per notebook, and swipl-wasm's foreign-library restrictions apply. Cold start is a couple of seconds on a mid-range phone.

It also runs Python, R, Bash and a few others, but that's a different post. The free edition is MIT and also runs in a desktop browser as a PWA if you want to poke at it without installing anything:

• Source: https://github.com/s243a/SciREPL

• Web demo: https://s243a.github.io/SciREPL/

• Google Play (free): https://play.google.com/store/apps/details?id=com.unifyweaver.scirepl

Happy to answer questions about how swipl-wasm behaves in a WebView, or what breaks.

Hi,

Logtalk 3.102.0 is now available for downloading at:

https://logtalk.org/

This is a major library-focused release featuring new natural-language processing, machine learning, numerical analysis, optimization, cryptography, networking, data interchange, identifier, and data structure libraries. It also significantly extends the MCP server and cryptography libraries, updates Unicode support, adds compiler and tool linter checks, and includes important HTTP reliability and portability fixes.

New libraries by category/area

Text processing / natural language processing

• lemmatization for extensible word lemmatization
• n_grams for generating and counting token and character n-grams
• stop_words for stop-word enumeration, membership testing, and filtering, with lists for six languages
• tokenization for extensible tokenization and sentence splitting
• text_normalization for Unicode-aware text cleaning and normalization
• text_vectorization for binary, count, term-frequency, and TF-IDF sparse vectorization
• language_detection for extensible text language detection

Networking / protocols / data interchange

• http_oauth for OAuth 2.0 Bearer request protection, protected-resource metadata, token introspection, and JWT verification
• http_sse for HTTP Server-Sent Events
• uri_template implementing RFC 6570 URI Templates
• mqtt implementing an MQTT 5.0 client
• smtp implementing a portable SMTP/ESMTP client
• bson implementing the BSON 1.1 binary interchange format
• gpx implementing the GPX 1.1 GPS data interchange format
• byte_order for signed and unsigned fixed-size integer conversions in big- and little-endian byte order

Cryptography / security

• paseto implementing Platform-Agnostic Security Tokens version 4
• block_ciphers providing portable AES-128, AES-192, and AES-256 implementations
• cmac implementing the NIST SP 800-38B Cipher-based Message Authentication Code

Mathematics / numerical methods / optimization

• integer_partitions for generating and querying integer partitions
• univariate_distributions for normal distribution sampling, density, log-density, cumulative distribution, and quantiles
• multivariate_distributions for multivariate normal and Student's t distributions, logistic-normal sampling, and Mahalanobis distances
• linear_programming for immutable construction and solving of small linear programs
• numerical_analysis for root finding, quadrature, interpolation, cubic splines, and non-stiff initial-value ODE solvers
• local_optimization for common box-constrained solvers
• constrained_optimization for common equality- and inequality-constrained solvers
• ant_colony, genetic_algorithm, differential_evolution, particle_swarm_optimization, and tabu_search metaheuristic optimization libraries

Machine learning / artificial intelligence

• association_rule_miner for deriving confidence- and lift-scored rules from frequent itemsets and sequential patterns
• mlp_classifier implementing a multi-layer perceptron classifier for continuous, categorical, and mixed tabular datasets
• one_class_svm_anomaly_detector implementing one-class SVM anomaly detection
• spectral_clusterer implementing normalized spectral clustering
• svr_regression implementing support vector regression with linear, polynomial, and radial basis function kernels
• tsne_projection and umap_projection for nonlinear dimension reduction
• trueskill_ranker implementing TrueSkill ranking for ordered multiplayer matches
• ripple_down_rules implementing SCRDR, MCRDR, and GRDR rule systems

Utilities / identifiers / data structures

• crontab for parsing and generating user and system crontab files
• lru_caches implementing immutable least-recently-used caches
• sqids for short, obfuscated, URL-safe encodings of non-negative integer lists
• typeid for type-safe, K-sortable, globally unique identifiers
• tries implementing prefix trees associating complete strings with values

Changed libraries by category/area

Cryptography / hashing

• crypto: added Ed25519 signatures, X25519 key agreement and authenticated ephemeral channels, XChaCha20-Poly1305 authenticated encryption, and bcrypt b2 support
• crypto: fixed PBKDF2 conformance with RFC 8018
• hashes: added generalized BLAKE2 functions accepting key and digest-size parameters
• hmac: documented BLAKE2 support and added HMAC-BLAKE2b and HMAC-BLAKE2s tests
• http_authenticate: updated for bcrypt b2 support

MCP

• mcp_server: added support for the 2025-11-25 and 2026-07-28 specifications
• mcp_server: added completions, resource templates, OAuth, MCP Apps, optional output schemas, and schema overrides
• mcp_server: improved reporting of tool-call failures and separated data-layer specifications from transports
• mcp_server: removed support for the deprecated 2025-03-26 specification

HTTP / networking

• http_process_transport: added full socat support and configurable connection helper executables
• http_process_transport and sockets: fixed connection teardown ordering to preserve buffered output
• HTTP transports: fixed per-connection error handling so listeners continue serving subsequent connections
• HTTP server and file-serving libraries: fixed partial-request disconnects and symbolic-link document roots
• http_process_transport: fixed an ncat shutdown race and OpenSSL command handling; OpenSSL 3.0.0 or later is now required
• http_router: now implements http_handler_protocol as a marker protocol
• http_parameters and http_router: now use standard domain errors for parameter validation

Mathematics / ranking / text

• linear_algebra: defined consistent empty-vector and zero-width matrix semantics
• ranking_protocols: added ordered multiplayer datasets with ranked teams and weighted player participation
• thurstone_mosteller_ranker and trueskill_ranker: now reuse shared distribution and normal-quantile functionality
• string_distance: added Caverphone and NYSIIS encodings and improved Metaphone and Double Metaphone
• list: improved the performance of nth0/3 and nth1/3
• random: fixed several API declarations, formulas, validations, and edge cases

Unicode / types / portability

• unicode_data: updated to Unicode 17.0.0 with reproducible generation, shared ranges, optional compatibility views, and preserved Unihan variant solutions
• types and arbitrary: added the open_probability type
• amqp, character_sets, hashes, ieee_754, and protobuf: updated to use the new byte_order library
• sockets and jwt: improved portability across supported backends

New and updated tools

Diagnostics / linting

• ports_profiler: added diagnostics for unexpected non-determinism in predicates declared with deterministic modes
• lgtunit: added a linter warning for invalid ^^assertion/1-2 goals
• lgtunit: now expands test assertions to avoid false dead-code warnings
• dead_code_scanner: now detects unused built-in predicates referenced through uses/2 and use_module/2 directives
• tutor: updated with explanations for the new compiler linter warnings

HTTP server automation

• Added logtalk_http_server.sh and logtalk_http_server.ps1 for starting servers using the Logtalk HTTP libraries with ECLiPSe, SICStus Prolog, SWI-Prolog, Trealla Prolog, and XVM

Compiler, runtime, and backend updates

• Added logtalk_linter_hook/7 support for linting super calls and messages to self
• Added warnings for cuts followed by goals that throw errors and for once/1 goals used as an if-then-else or soft-cut condition
• Fixed the arithmetic_expressions flag
• Fixed the ordering of initialization/1 directive goals found in included files
• Fixed false missing-predicate reports from logtalk_make(check) for complementing categories
• Updated Trealla Prolog tabling and linter support; Trealla Prolog 3.9.64 or later is now required
• Updated SWI-Prolog proprietary predicate metadata used by the linter

Documentation, examples, and other updates

• Added a Handbook section on third-party library dependencies and improved manual installation instructions
• Added examples for HTTP Server-Sent Events, MCP servers, and MCP Apps
• Updated the birds_mcp example for the 2026-07-28 MCP specification
• Improved multi-threaded examples to avoid possible random-number generation races
• Added negative-duration support to the iso8601 contribution
• Updated the portable Docker image and VSCode code-navigation support

Thanks to Andrew Davison for the Trealla Prolog patch, performance and networking reports, and multi-threading analysis, and to Lindsey Spratt for the rest library performance fix.

For details and a complete list of changes, please consult the release notes at:

https://github.com/LogtalkDotOrg/logtalk3/blob/master/RELEASE_NOTES.md

Happy logtalking!
Paulo

I have renamed the project SCBM-Prolog and am restarting its development under this new name.

For some time, I was not fully satisfied with the timing of failure-continuation generation. I kept looking for a simpler and theoretically cleaner approach.

I tried several alternatives, and some of them worked partially, but they always failed when backtracking became more complex.

Finally, I figured out why.

The approach itself was fundamentally impossible.

The timing of continuation generation is not just an implementation detail. A continuation has to be created at the right moment, when the actual execution state it represents is known.

I have written about what I discovered in more detail here:

URL　SCBM-Prolog: Problem Solved. On a holiday, I accompanied my elderly… | by Kenichi Sasagawa | Sep, 2026 | Medium

From now on, I will continue improving SCBM-Prolog (Sasagawa Continuation Backtracking Model) with the goal of making it a practical Prolog implementation.

Project:

URL　sasagawa888/scbm: SCBM (Success Continuation Backtracking Model) is an experimental execution model for Prolog. It explores a simple alternative to the WAM, using explicit success and failure continuations and direct compilation to C.

https://github.com/ZViperSw/bf-intepeter-pro/tree/main

Link:

https://github.com/ZViperSw/bf-intepeter-pro/tree/main

The syntax of this language is so weird it makes bf seem like babys work.

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

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