The concepts described in the book manuscript are accompanied by a running implementation: the Trinity demonstrator, a live system you can try in your browser right now. Readers who wish to try things out — to run a query against a live node, to spawn an actor, to load and exercise a statechart actor, to make remote procedure calls between nodes that put the distributed side of things on display — will find the demonstrator a useful companion. It is an attempt to make the essential ideas observable, reproducible, and interactable, rather than merely readable.
Two caveats deserve mention. First, this is a proof-of-concept, not a production system. The demonstrator is hosted with best-effort availability, and readers should not be surprised if it is occasionally unreachable. Second, the implementation covers SWI-Prolog specifically. But the book's proposals are intended to be implementable on other Prolog systems as well, and one of the long-term goals of the Trinity project is to encourage independent implementations that can be compared and tested for interoperability. SWI-Prolog remains by far the most important proof-of-concept implementation for the book, providing the integrated demonstrator and its actor and statechart examples. Its implementation remains open to revision as these complementary prototypes reveal differences and hidden assumptions.
The implementation work has been done in cooperation with several AIs.
This implementation is much smaller and is written for clarity. The code is meant to be read alongside the book. As a result, a number of features are absent or only partially sketched out. It is one of many starting points if your goal is to understand how Web Prolog nodes work from the inside, or if you want to port its core components to another Prolog system.
This proof of concept ports the simple node's actor runtime and related facilities to Trealla Prolog, with current reported tests using v3.12.6. It supports selective receive, links and monitors, private source contexts, resumable toplevels, HTTP remote procedure calls, promises and yield. A native WebSocket transport implements the Trinity version-1 actor protocol, with persistent connections for remote spawning, messaging and toplevel control.
The reported tests exercise both Trealla-to-SWI and SWI-to-Trealla interactions. The separate Trinity conformance suite also contains draft cases exercised against both runtimes; passing those cases does not establish complete ACTOR conformance. The port includes policy enforcement, authentication and resource governance, but remains a proof of concept. Current limitations include incomplete TLS hostname verification, empty private modules retained until process exit, and reliance on process or container containment for resources without equivalent runtime ceilings.
This proof of concept explores implementing a Web Prolog ISOBASE node with GNU Prolog and a loopback C HTTP server. It supports submitted source, JSON bindings, Prolog-text answers, live pagination, a shared database, and HTTP(S) remote procedure calls, promises and yield. Each active query has its own operating-system process, preserving bindings and choice points between pages until completion, cancellation or expiry. C supervisors manage deadlines, resource bounds and cleanup. Validated shared predicates can optionally be compiled into a native node bundle; request-local source remains interpreted.
Reported tests cover GNU-to-GNU, GNU-to-SWI and SWI-to-GNU interoperability, timeouts, cleanup and access policy. The process-worker design suits GNU Prolog's query interface and lack of general heap garbage collection; ISOBASE is the immediate target, with ISOTOPE a possible later extension. Remaining profile facilities, compatibility gaps and hard security isolation are still open work. Memory budgets are sampled and may overshoot their configured limits. These results demonstrate selected interactions, rather than complete ISOBASE conformance or readiness for arbitrary public deployment.
This is an attempt to port the simple node from SWI-Prolog to Ciao Prolog. This is only a port of a node (i.e. no actors, send or receive) and uses engines rather than threads.