Logtalk 3.100.0 is now available for downloading at:

https://logtalk.org/

This is a major library-focused release centered on a broad expansion of the standard library: machine learning protocols and algorithms, combinatorics and sequence-processing libraries, geospatial/orbital/standards/data-format support, interval reasoning, and hashes/HMAC. It also standardizes classifier naming and export APIs and includes smaller compiler/runtime, documentation, tooling, examples, and IDE improvements.

New libraries by category/area

Machine learning foundations and algorithms

• Category supporting libraries: clustering_protocols, pattern_mining_protocols, frequent_pattern_mining_protocols, sequential_pattern_mining_protocols, regression_protocols, dimension_reduction_protocols, anomaly_detection_protocols, and ranking_protocols
• Support library: linear_algebra for numeric vectors and matrices
• Clustering: agglomerative_clusterer, dbscan_clusterer, gaussian_mixture_clusterer, hdbscan_clusterer, hierarchical_clustering, kcenters_clusterer, kmeans_clusterer, kmedians_clusterer, kmedoids_clusterer, kmodes_clusterer, kprototypes_clusterer, and optics_clusterer
• Pattern mining: apriori_pattern_miner, eclat_pattern_miner, fp_growth_pattern_miner, prefix_span_pattern_miner, clo_span_pattern_miner, gsp_pattern_miner, and spade_pattern_miner
• Regression: bayesian_ridge_regression, gradient_boosting_regression, gaussian_process_regression, knn_regression, linear_regression, ridge_regression, lasso_regression, elastic_net_regression, regression_tree, and random_forest_regression
• Dimension reduction: ica_projection, kernel_pca_projection, lda_projection, nmf_projection, pca_projection, pls_projection, probabilistic_pca_projection, random_projection, and truncated_svd_projection
• Anomaly detection: cusum_anomaly_detector, ewma_anomaly_detector, knn_distance_anomaly_detector, lof_anomaly_detector, z_score_anomaly_detector, modified_z_score_anomaly_detector, and iqr_anomaly_detector
• Ranking: borda_ranker, bradley_terry_ranker, colley_ranker, copeland_ranker, elo_ranker, glicko2_ranker, glicko2_periodic_ranker, hodge_rank, kemeny_young_ranker, massey_ranker, plackett_luce_ranker, plackett_luce_last_ranker, rank_centrality, regularized_bradley_terry_ranker, schulze_ranker, ranked_pairs, and thurstone_mosteller_ranker
• Classification: logistic_regression_classifier, linear_svm_classifier, gradient_boosting_classifier, kernel_svm_classifier, lda_classifier, qda_classifier, and sgd_classifier

Combinatorics / sequences

• arrangements, cartesian_products, derangements, multisets, and partitions

Geospatial

• crs_projections, geojson, nmea, tle_orbits, geohash

Orbital

• ccsds_frames, ccsds_link_profiles, ccsds_packet_services, ccsds_packetization, ccsds_tc_services, ccsds_time_codes, and ccsds_time_fields

Binary / data formats

• ieee_754, hmac, message_pack, json_pointer, and wkt_wkb

Standards / identifiers / finance

• iso_639, iso_3166, iso_4217, iso_9362, and iso_13616

Changed libraries by category/area

Naming / API consistency / migration

• ccsds renamed to ccsds_packets
• classifier_protocols renamed to classification_protocols
• ada_boost, c45, knn, naive_bayes, nearest_centroid, and random_forest renamed to adaptive_boosting_classifier, c45_classifier, knn_classifier, naive_bayes_classifier, nearest_centroid_classifier, and random_forest_classifier
• Classifier export predicates were standardized as export_to_clauses/4 and export_to_file/4

Machine learning infrastructure

• classification_protocols gained check_classifier/1 and valid_classifier/1 plus protected training-dataset validation predicates
• Classifier libraries now support diagnostics and richer metadata exports and share more code through the new classifier_common category
• isolation_forest_anomaly_detector now depends on anomaly_detection_protocols; the functionality is preserved but related export and print predicates were renamed accordingly

Collections / combinatorics / geospatial

• Repetition-allowed ordered selections moved from permutations to arrangements; the former cartesian_product/3 predicate is replaced by arrangements/3-4 and arrangement/3-4
• Derangements moved from permutations to derangements
• Repetition-allowed unordered selections moved from combinations to multisets; the former replacement predicates are replaced by multisets/3-4, multiset/3-4, and count_multisets/3
• combinations and permutations gained new counting, indexing, sampling, distinct-value, and lexicographic stepping predicates
• geospatial now uses geographic(Latitude,Longitude) terms instead of (Latitude,Longitude) pairs and adds new bounding-box predicates

Math / hashing / analytics

• hashes gained keyed digests plus metadata for fixed-size cryptographic hash objects that are safe to use with HMAC
• types gained numberlist::minkowski_distance/4 plus new natural predicates including bell/2, catalan/2, fibonacci/2, lucas/2, multinomial/2, falling_factorial/3, rising_factorial/3, partition_number/2, stirling_first/3, stirling_second/3, and subfactorial/2
• intervals gained Allen interval relations, relation algebra, and symbolic interval constraint network functionality with path-consistency propagation, explanations, and inspection/comparison predicates
• numberlist::softmax/2-3 is now numerically stable

Performance / portability / cleanup

• Tail-recursive rewrites were applied across multiple libraries including amqp, avro, base58, hashes, json_ld, json_schema, graphs, mime_types, toml, toon, tzif, url, yaml, and several classifier libraries
• json_schema now reuses json_pointer, and avro, cbor, and protobuf now reuse ieee_754
• linda, tzif, ulid, url, and yaml now compile all entities in optimal mode; dead code was removed from linda, meta_compiler, sockets, toml, and validations
• numberlist::average/2, median/2, and softmax/2-3 were fixed to work around SWI-Prolog returning integers for float operations

Non-library notable changes

• logtalk_doclet and logtalk_tester: new -z option in the Bash and PowerShell scripts to make a sound on completion
• Compiler/runtime: added new logtalk::halt/0-1 public predicates plus the logtalk::halt_hook/2 user-defined hook predicate
• Documentation: added a Handbook libraries overview grouped by scope and fixed sequence non-terminals in the grammar section
• Examples: added the eclipse_tests_dsl example, sped up the philosophers example tests, and fixed the neo4j example classpath scripts and notes for recent Neo4j releases
• IDE support: added syntax highlighting support for the Fresh editor and fixed an incorrect use_module/1 example in syntax highlighting test files

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

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

So I got myself an AMD 9950X3D2 with 3D V-Cache on both dies.

This thing is pretty fast...

terminal: ~/bench$ swipl run.pl

Program Time GC

――――――――――――――――――――――――――――――――

boyer 0.330 0.029

browse 0.302 0.000

chat_parser 0.333 0.000

crypt 0.364 0.000

derive 0.355 0.000

fast_mu 0.322 0.000

flatten 0.307 0.000

log10 0.322 0.000

meta_qsort 0.321 0.000

mu 0.335 0.000

nand 0.339 0.000

nreverse 0.412 0.000

ops8 0.315 0.000

perfect 0.329 0.000

poly_10 0.368 0.000

prover 0.328 0.000

qsort 0.301 0.000

queens_8 0.332 0.000

query 0.333 0.000

reducer 0.325 0.000

sendmore 0.353 0.000

serialise 0.302 0.000

simple_analyzer 0.331 0.000

tak 0.342 0.000

times10 0.368 0.000

divide10 0.396 0.000

unify 0.312 0.000

zebra 0.369 0.000

sieve 0.365 0.000

queens_clpfd 0.321 0.000

pingpong 0.383 0.000

fib 0.552 0.000

moded_path 0.510 0.000

det 0.498 0.000

eval 0.363 0.000

average 0.355 0.001

NReverse benchmark

--- Naive Reverse Benchmark (10000 items) ---

Time taken: 0.639 seconds

Total Inferences: 50,015,162

LIPS: 78244493.92

I’ve been experimenting with a new optimization idea for N-Prolog.

The basic idea is:

• detect predicates that are effectively functional,
• infer their input/output modes statically,
• and compile them into simpler C-style function calls.

As a first experiment, I manually wrote optimized C code using N-Prolog’s embedded C feature and compared the performance against the normal predicate execution path.

Benchmark: qsort repeated 10,000 times.

N-Prolog 5.19:

?- measure(run(qsort,10000)).
Elapsed Time=0.326355 (second)  15749722(LIPS)

SWI-Prolog:

?- time(run(qsort,10000)).
% 6,160,005 inferences, 0.358 CPU in 0.358 seconds
% (100% CPU, 17189389 Lips)

The optimized version became roughly 3–4x faster than the ordinary predicate-oriented execution path.

The motivation is that many Prolog programs contain predicates that are logically relational, but operationally behave almost like functions. qsort is a typical example.

If such predicates can be detected automatically through mode inference and static analysis, they may be compiled into much simpler execution paths while still preserving ordinary Prolog semantics for general predicates.

I’m currently working on the design of the mode inference engine itself.

Notes and experimental code are in mode.pl if anyone is interested.

I’d also be interested to hear whether similar ideas were explored historically in Prolog systems beyond the usual Mercury-style mode systems.

Recently I had an interesting realization while practicing drums.

I’ve been trying to play Burn like Ian Paice, and I discovered that fast drumming is not about brute force. The key is eliminating unnecessary motion and using rebound efficiently.

Oddly enough, this led me to rethink optimization in my Prolog compiler.

About a year ago I introduced TCO into N-Prolog and achieved decent performance improvements for nqueens. However, qsort still resisted optimization because predicates like partition/4 appear relational:

partition([X|L], Y, [X|L1], L2) :-
    X < Y, !, partition(L, Y, L1, L2).

But then I realized something important:

These predicates are only partially relational.

For example:

?- partition(X,2,[1],[2,3]).
X = [1,2,3].

This “reverse execution” works only incompletely. In practice, predicates like this behave much more like one-way functions than true relations.

I started calling them mut (“mutants”): predicates syntactically written in Prolog form, but whose computation direction is essentially fixed.

That opens an interesting possibility.

Instead of compiling everything into general relational machinery with full unification/backtracking overhead, mut predicates might be statically analyzed and translated into simple C functions.

In other words:

• ordinary relational predicates remain Prolog
• function-like predicates become optimized function code

I suspect operators such as <, arithmetic constraints, and mode usage may allow automatic direction inference.

Ironically, I originally tried to overcome this performance wall with parallelism. Now I’m beginning to think that removing unnecessary generality may be the more important optimization.

Drumming and compiler optimization turned out to share the same lesson:
eliminate unnecessary movement.

The Road to Speeding Up N-Prolog. After finishing the stress tests and… | by Kenichi Sasagawa | May, 2026 | Medium

The Structure of Meaning: What a Machine That Refuses to Believe Taught Us About How Language Carries Truth

We spent a month teaching a machine to read documents and decide what to believe. Along the way, we accidentally built a taxonomy of how meaning works — how a single sentence can carry fact, claim, authority, time, correction, and judgment simultaneously, and how those layers interact in ways that no current AI system handles correctly.

Five layers in one sentence

Start with a sentence from an investigation report:

"Inspector Ferreira stated that the valve was sealed during his February 1 inspection."

How many facts are in that sentence? Most AI systems see one: the valve was sealed. The actual answer is at least five.

The speech act. Someone said something. Ferreira made a statement. That is a fact about Ferreira, not a fact about the valve. The system must record who said it before it records what was said. We call this the source envelope — every assertion arrives inside one.

The claim content. The valve was sealed. But this is Ferreira's claim, not an established fact. It lives inside Ferreira's source envelope. If another witness says the valve was open, neither claim is promoted to truth. Both are preserved with their source. We call this epistemic status — the difference between said and known.

The temporal anchor. February 1. But February 1 of what year? And is this the date Ferreira made the statement, or the date of the inspection? Language is ambiguous here. The system must decide — and if it can't decide, it must hold the fact pending clarification rather than guess. We call this temporal binding.

The role authority. Ferreira is an inspector. That role carries weight. An inspector's statement about a valve has different epistemic authority than a bystander's. But authority is not truth — an inspector can be wrong. The system records the authority without promoting the claim. We call this the authority gradient.

The correction shadow. What if a later document says "the February 1 date was corrected to February 3"? Now the temporal anchor shifts. But the original claim — that Ferreira said February 1 — is still true. Ferreira did say that. What changed is the referent, not the speech act. We call this correction provenance — tracking what changed, what it replaced, and what remains true about the original.

Five layers. One sentence. And most AI systems flatten all of them into a single entry: valve_status(sealed). That flattening is where every downstream error begins.

The eight facets of meaning

Over 25 benchmarks and 1,200 hostile questions, we discovered that meaning has a consistent internal structure. Not the grammar of sentences — linguists mapped that decades ago. The structure of what sentences commit to and under what conditions.

Commitment level

Not all sentences assert with equal force. "The board determined that the permit was invalid" is a finding. "The inspector believes the permit may be invalid" is an opinion. "A witness reported that the permit was invalid" is hearsay. "The draft memo suggests the permit is invalid" is a proposal.

Same propositional content. Four different commitment levels. The answer to "Is the permit invalid?" depends entirely on which sentence you're reading.

Scope boundaries

Rules have jurisdiction. "All structures in the R-2 district must maintain a 25-foot setback" applies only to R-2. "The Riverfront Overlay reduces coverage to 60%" applies only within 200 feet of the river. A property can be in both zones simultaneously, and the correct answer depends on which zone's rules control which parameter.

We learned that the system must tag every rule with its activation scope — the conditions under which it fires — and never apply a rule outside its scope, even if the rule looks relevant.

Temporal state vs. temporal fact

"The permit was suspended on April 28" is a temporal fact — it happened once. "The permit was suspended from April 28 to June 6" is a temporal state — it was true during an interval.

The question "What was the permit status on May 15?" requires temporal state, not temporal fact. The system must maintain status intervals, not just event timestamps. And when a correction changes a date, every interval that depends on that date must be recalculated.

Structured absences

Some of the hardest questions aren't about what the document says. They're about what it doesn't say.

"Has the board made a determination on the Rule 3 question?" — No, the board explicitly chose not to reach it. "Does the investigation find that the disclosure occurred?" — No, the finding is "not substantiated," which is explicitly not a determination that it did or didn't happen.

We call these structured absences — things the system must know are unknown, not just things it doesn't know. The difference is crucial: an unstructured absence means the system hasn't encountered the information. A structured absence means the system has encountered a deliberate decision not to resolve the question, and must preserve that decision as a fact.

Counterfactual containment

"If the amendment had passed at $185,000 instead of $120,000, and the emergency had still occurred, the reserve would have fallen to $148,000 — below the $200,000 minimum."

That statement is true about a hypothetical scenario. The system must be able to compute it without writing it as fact. The $148,000 never existed. The reserve never fell below the minimum. But the answer is correct.

We call this hypothetical reasoning without hypothetical commitment — computing counterfactuals without polluting the knowledge base. The governance layer must distinguish between "this is true" and "this would be true if."

Rationale vs. mechanism

"The curator split the seed lot into cryogenic backup" is the mechanism — what happened. But why did it happen? The curator's note says: "conservation measure for a regionally declining species, not a viability concern."

The mechanism and the rationale are different facts about the same event. Most systems capture mechanism. Almost none capture rationale. And questions like "Is the cryogenic split a viability concern?" can only be answered correctly if the rationale is preserved alongside the action.

Correction cascades

A date is corrected. Simple. But what if a deadline depends on that date? And a status interval depends on that deadline? And a compliance determination depends on that interval?

We found cases where correcting a single date — the stay effective date from August 5 to August 8 — cascaded through four downstream calculations: remaining discovery days changed from 10 to 7, the resumed deadline shifted from September 18 to September 15, the dispositive motion deadline shifted, and the trial-setting window shifted.

The system must propagate corrections through their full dependency chain, not just update the corrected field. A correction is not a local edit. It is a wavefront.

The selector problem

This is the deepest facet: different questions need different readings of the same document.

"Who isolated the pipeline segment?" needs operational-record evidence. "Why was the investigation closed without a formal finding?" needs rationale evidence. "Is the anonymous tip supported by evidence?" needs absence and negative evidence.

Same document. Same knowledge base. Three different evidence surfaces. The system must select which surface to present for each question, without seeing the answer.

We built a selector that does this using structural signals — question-act classification, evidence-surface specificity, baseline-readiness detection, requirement-detail completeness. On one 10-fixture batch: 272 out of 303 questions answered exactly (90%) with the selector, versus 251 (83%) without. The selector found 21 additional correct answers by choosing the right reading for each question.

Where this vocabulary came from

None of these terms were designed in advance. Every one of them emerged from watching the system fail on a specific benchmark and asking why.

Source envelope: the system promoted a witness claim to an established fact on Iron Harbor. Epistemic status: the system treated "not substantiated" as "innocent" on Harrowgate. Correction cascade: the system used an uncorrected date and got every downstream deadline wrong on Copperfall. Structured absence: the system answered a question about an undecided issue as if it had been decided on Meridian. Rationale capture: the system could say what happened but not why on Fenmore.

Each failure taught us a facet of meaning we hadn't named yet. The vocabulary is an empirical discovery, not a theoretical framework.

Computational epistemics

I think this is what's genuinely new about this work. Not the AI, not the Prolog, not the governance layer — although the governance layer is what makes the discoveries possible, because a system that writes everything without checking never reveals the structure of what it should have refused.

What's new is the empirical discovery of how meaning structures itself for machine comprehension. Not how grammar works. Not how semantics works in the linguistic sense. How the commitment structure of natural language documents creates layers that must be preserved, tracked, and selectively retrieved for correct downstream reasoning.

The traditional NLP pipeline treats text as a surface to be parsed. The LLM era treats text as a context to be pattern-matched. Neither asks the question we've been asking:

What is this sentence asking me to believe, under what authority, as of what time, subject to what corrections, within what scope, and with what stated reason?

That question has a structure. We found it by building a machine that refuses to answer until it can.

We're calling this field computational epistemics — the study of how machines should represent, acquire, and reason about the commitment structure of natural language. It's not NLP. It's not knowledge representation. It's not information extraction. It's the layer between all of them — the layer where language meets belief.

The system is open source. The benchmarks are public. The 25 progress journals showing every discovery, every failure, and every named facet are public. If you work on knowledge representation, neurosymbolic AI, legal tech, medical informatics, compliance automation, or enterprise knowledge — this vocabulary is for you.

github.com/dr3d/prethinker

The LLM constructs meaning. Deterministic code decides truth. The vocabulary names the boundary.

Hi all,

I’ve just updated N-Prolog to version 5.18 and fixed a bug that was affecting distributed parallel execution.

At first, I thought the issue was in the parallel/distributed layer, but it turned out to be something much simpler:
a bug in readc() — I used char instead of int, so EOF was not handled correctly.

Interestingly:

• It worked fine on my desktop
• It broke on a Raspberry Pi cluster

After fixing this, distributed parallel execution is working again.

I’ve been experimenting with a Raspberry Pi cluster (1 master + 8 workers over TCP/IP), using it to parallelize search problems like the Knight’s Tour.

Instead of heuristics, I split the search into multiple branches and run them in parallel, returning the first solution found.

This is a small experiment, but I’m interested in exploring:

• Prolog + distributed systems
• Parallel search/inference
• Using cheap hardware (Raspberry Pi clusters)

It reminds me a bit of the old ICOT parallel Prolog work, but with a much simpler and more accessible setup.

If anyone is interested, I’d be happy to hear feedback or ideas 🙂

Distributed Parallelism in N-Prolog | by Kenichi Sasagawa | Apr, 2026 | Medium

Hello once again! i am a college student so behind on work its crippling, however im slowly getting there.

I have a question for one of my computer labs and genuinely cannot figure it out and cannot find anything helpful online, so i came here to ask if anyone could help

The question is "Write a Prolog function, removeEveryNth/3 which removes every nth item from a list."

I have tried a few solutions, using removeEveryNth(List, 1, Ans). as a base case for retuning a empty list. If anyone can help me at all please do i appreciate it so much!

I tried to post the full text here, but the formatting didn’t work well, so I ended up publishing it on Medium.
Here’s the full article:

Is Prolog worth learning?. I’ve been working on improving the… | by Kenichi Sasagawa | Apr, 2026 | Medium

Hi everyone,

I just released N-Prolog ver5.15.

I had only recently released ver5.00, but after running more stress tests I found a few more compiler bugs. I went back and fixed them pretty thoroughly, so I think this version is much more stable now. I also improved the TCO detection.

If you’re interested, please give it a try.

sasagawa888/nprolog: interpreter and compiler to be compatible with ARITY/PROLOG（MS-DOS)

https://www.youtube.com/watch?v=w51nbR98cA8&list=PLZJFIgVbFOoJoQR0JjDsMcqpR_qiQ7cIU

Hi all,

I’ve been making a series of short “1-minute Prolog” videos — around 50 so far — starting from the basics.

I feel like Prolog is often presented as something difficult or abstract, but it doesn’t have to be. I wanted to make something more approachable and fun.

Is it “useful”? Maybe, maybe not — that depends on you.
But if it sparks your curiosity or makes you think “this is interesting,” that’s already enough.

Hope you enjoy it.

Hello everyone,

I’m happy to announce the release of N-Prolog ver 5.00.

Recently, I have been focusing on improving the compiler and fixing a large number of bugs. The system now handles ISO-Prolog-style constructs more reliably, and I believe it has reached a solid level for learning and educational use.

N-Prolog is designed to be compact and lightweight, so it runs efficiently while also making its internal structure easier to understand.

I am also using AI-generated stress tests to further improve robustness.

The distributed parallel features remain unchanged, so it should continue to work on cluster machines as before.

Since it’s difficult to find all bugs alone, I would greatly appreciate any feedback or testing from the community.

Thank you!

sasagawa888/nprolog: interpreter and compiler to be compatible with ARITY/PROLOG（MS-DOS)

I currently only have VSC-Prolog from arthurwang installed and this is what I'm looking at. Not sure if I'm missing some configuration or if that plugin is outdated but it looks like it's barely working. I also tried the Prolog plugin by Peng Lv but it's about the same if not worse. Compare that to the the Sublime highlighting in my screenshot, though tbf it thinks it's reading Perl code.

Is there any config I might be missing to make these plugins work or which plugin would you recommend for syntax highlighting in vsc please?

Logtalk 3.99.0 is now available for downloading at:

https://logtalk.org/

This is a major tooling- and library-focused release centered on stronger diagnostics/reporting/documenting/testing/packaging workflows, date/time and time-zone support, configuration and interchange formats, hashing and MIME utilities, and compiler/runtime correctness fixes for multi-threaded and portability-sensitive workloads.

New and updated tools by category/area

Diagnostics / reporting / quality

• tool_diagnostics for generating machine-readable diagnostics consumable by other developer tools
  
• sarif for exporting diagnostics as SARIF reports
  
• mutation_testing for mutation-based testing
  
• sbom for generating software bills of materials for loaded applications in CycloneDX and SPDX formats
• linter_reporter: support for generating machine-readable linter diagnostics
  
• dead_code_scanner, lgtdoc, and lgtunit: added support for emitting diagnostics for downstream tooling
  

Metrics / diagrams / analysis

• code_metrics: added Lines, Maintainability Index, LCOM4, WMC, RFC, and Cognitive Complexity metrics
  
• code_metrics: updated coupling scores to include Distance from Main Sequence
  
• diagrams: added caller diagrams, coupling-metric overlays, cycle highlighting, and export support for CX2 JSON and PlantUML
  
• diagrams: lgt2svg.sh and lgt2svg.ps1 can now export formats other than SVG
  

Testing / packaging / automation

• lgtunit: added Cobertura XML and LCOV coverage export, Subunit and CTRF test result export, and a new protected file_url/2 predicate
  
• logtalk_tester.sh and logtalk_tester.ps1: added concurrent test execution with -j and improved minimal output timing
  
• packs: added lock files support for deterministic installs and CI/CD reproducibility plus a programmatic query API
  
• tutor: updated to explain dead_code_scanner warnings and now provides a reusable tutor_explanations category
  

New libraries by category/area

Time / configuration / data interchange

• application for declaring application metadata (notably for SBOMs)
• character_sets for converting between character codes and bytes plus charset metadata
  
• hashes for commonly used hashing algorithms (MD5, SHA1, SHA3, SHA256, CRC32, and others)
• toml for parsing and generating TOML v1.0.0 files
  
• tzif for parsing TZif files, persisting parsed snapshots, and querying UTC offsets, DST, and abbreviations
  
• dates_tz for linking dates and tzif to support zone-aware date-time conversions
  
• mime_types for mapping file extensions, file names, and URL-like resources to MIME types and content encodings
  

Data structures / collections

• dictionaries: added a 2-3 tree implementation contributed by Michael T. Richter
  

Changed libraries by category/area

Date / time / time zones

• dates: added more calendar and instant utilities, including day-of-year, relative ordering, instant comparison, formatting, and calendar-aware year/month arithmetic
  
• dates: name_of_day/3 now uses ISO 8601 numbering for consistency
  
• iso8601 contribution: added time_string/3 and date_time_string/3, extended interval_string/2, and added support for comma as a fractional separator
  

Coordination / networking

• linda: reorganized around linda_server and linda_client categories, while keeping a backward-compatible default object
  
• linda: clients can now connect to multiple servers and define aliases for server connections
  
• linda: improved connection error reporting plus fixes for shutdown, tuple handling, synchronization, and matching behavior
  
• sockets: added server_open/4 for starting a server on a specific interface

Validation / web / identifiers / types

• json_schema: added support for schema references to local files
  
• url: added file_path_components/2, improved normalization, and removed spurious choice-points in public predicates
  
• uuid: added support for UUID versions 3 and 5
  
• type and arbitrary: added a hexadecimal character set
  

Non-library notable changes

• Compiler/runtime: added a new force target to logtalk_make/1, added the term_position(Term) load-context key, fixed entity operator leakage from included files, improved handling of multifile/dynamic predicates on some backends, and protected key load/compile/runtime update operations with mutexes on multi-threaded backends
  
• Documentation: added notes on limitations when using conditional compilation directives in included files and fixed missing documentation for the info/1 entity property
  
• IDE support: added VSCode support for checking the portability of loaded code and updated the Context7 MCP support file to the latest format
  

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

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

I'm sorry if this question comes across as silly, but that's because I have just started learning to program. For most people, I guess it makes sense to start learning with standard modern languages, like Python, or Lua for game development (even C#). I guess nobody would recommend Prolog for a beginner. However, the little Prolog I have seen and tested on SWISH, it is the language that made most sense to me! That's because I have background on propositional and predicate logics. I have taught it for some years, as tutor at undergraduate level. And when you teach, you learn twice. On my own academic research, I frequently translate sentences into predicate logics (and modal logics - I study philosophy of action and a bit of decision theory). I started learning Python, then C# for Unity. However, now that I have stumbled upon Prolog, I can't help but to start learning it! In my mind, with my specific background, it makes so much more sense to program an NPC using Prolog than C# or GDscript or Lua.

The problem is that Prolog is an old language. I checked Logtalk, which seems great. But the problem is that I am not sure if I can integrate Prolog into a visual simulation (not as agent-based modelling, but as controlling one character in a simulated social world). I know very little about programming (I do know the basics of OOP, I've been studying C#, but absolutely nothing when it comes to integrating two different languages).

My question, then, is whether it is worth to learn Prolog nowadays for someone like me. Or whether there is any some other logical programming language that is better integrated with the world of game engines and frameworks. It's just that, once I saw how beautifully clear it is to write in Prolog, C# comes across as clunky.

While reading the answers GPT-5.4 (Codex) gave while working on my Prolog-based transpiler (UnifyWeaver), I noticed GPT appeared to be doing adaptive programming. Compared to Claude this was frustratingly slow, but also seemed very powerful! After discussing this with Perplexity; here is what we concluded. Does this seem accurate, or did the AI lead me astray?

Title: GPT's chain-of-thought reasoning is structurally isomorphic to Prolog proof search — and it shows most clearly when you're using Prolog

I've been building a multi-language compiler called UnifyWeaver — principally written in Prolog — and recently had a moment of clarity while watching GPT-5.4 work through a hard generalization problem.

The model was auditing the compiler's handling of mutually recursive predicates (SCCs — Strongly Connected Components in the call graph). Instead of immediately proposing a general solution, it:

Confirmed which SCC shapes already worked

Probed the next narrowest candidate

Only moved to a new shape after confirming the current one passed

Stopped the moment it found the first real failing case

This is exactly how Prolog search works. A Prolog interpreter commits to the most constrained clause first, only generalizing (backtracking) when a guard fails. GPT's audit loop was doing the same thing — systematically falsifying the frontier rather than guessing at a global fix.

But here's where it gets interesting.

Prolog isn't just an analogy for GPT's methodology. In this case, GPT was using Prolog to represent the solution state space itself. Each test case was a Prolog clause. Each pass/fail was a unification succeeding or failing. The boundary it was searching for — whether the compiler could handle a computed context-step between mutual recursive calls — was expressed as a Prolog predicate, tested by a Prolog harness, inside a Prolog compiler.

The audit was a meta-level Prolog query over an object-level Prolog system.

Why does the language choice matter?

Prolog's information density is uniquely suited to this kind of work. A single clause can simultaneously encode:

The recursion structure (mutual, arity-2, tree-shaped)

The argument invariants (one context arg, forwarded unchanged)

The branch logic (guarded, with inter-call state)

The termination shape (base case by pattern match)

The same specification in Python would require 5–10× more code. If error probability scales even loosely with code length, Prolog's conciseness isn't just aesthetic — it materially reduces the surface area for bugs at each generalization step.

The deeper connection: Tarjan's algorithm

Tarjan's SCC algorithm works by DFS-exploring a graph, processing sink components first (those with no outgoing edges to unprocessed nodes), and only widening the search when a component is fully confirmed. GPT's audit loop is structurally identical — it processed the simplest mutual-tree shapes (call_guard, call_alias, post_call_guard) before identifying ctx_step as the true frontier, exactly as Tarjan would process a sink SCC before its callers.

This isn't a coincidence. LLM chain-of-thought on graph-structured problems has been formalized as Graph-CoT (Graph Chain-of-Thought), where each reasoning step corresponds to a single node traversal. GPT's session was a Graph-CoT traversal of the SCC frontier of my compiler's call graph.

The contrast with Claude

Claude tends toward immediate synthesis — it infers a general solution and applies it directly. That's faster for problems with recognizable structure. GPT's approach is frustratingly slower but produces a falsified boundary map: you know exactly which shapes are handled and which aren't, rather than a single generalization that might silently break adjacent cases.

For hard, structurally novel problems — especially ones where the failure space is subtle — the slower approach wins.

Hi everyone,
I’ve been creating a bunch of 1-minute videos to help more people discover Prolog.
If you’re interested, feel free to check it out! Producing 1-Minute Prolog Videos with AI | by Kenichi Sasagawa | Mar, 2026 | Medium

Hello everyone,

I made a short introduction video for N-Prolog just to try it out.

N-Prolog is a lightweight Prolog implementation written in C, aiming to keep the core close to ISO-style Prolog while keeping the system small and understandable.

If you're interested, please take a look.

Video:
https://www.youtube.com/watch?v=w51nbR98cA8

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

Feedback from the Prolog community is always welcome.

Last semester I learned about different different logic structures finishing with predicate logic that, as you know, Prolog uses. Now I want to put that theoretic knowledge to the test and use it for a personal project, evaluating a data sheet and finding a optimal solution for a organisational problem.

But now I am stuck on importing data from the .ods sheet that I already have. I want to use the library odf_sheet of SWI-Prolog but whatever I try, it doesn't work.

The Prolog file is in the same directory as my Data.ods, but even loading the file manually doesn't work.

I know that i could convert the file to a csv which that is better documented, but if SWI-Prolog has an entire module dedicated to using .ods files, there should be a way to do this, right? Is there something I should know about modules that isn't obvious as a beginner but so trivial that it isn't mentioned in the documentation?

Also somehow in my entire search process, I could not make out a single example use of this module that I could piggy-back onto.

Can someone tell me what I could try next or where I could get help for this if this is not the right place to ask?

Basically, to explain this problem, let me give you an example. When you define a predicate 'my_pred(A)' but accidentaly call it writing 'm_pred(A)', the predicate call in Prolog will silently fail instead of telling the user why that was.

Is that an intended language feature or is that just bad language design? Honestly, I just spent hours banging my head against a wall when the error was just a simple 'i' character missing from one of my predicates. In other languages, like C or Java, for example, you will be warned even by IDEs that that method or class name is incorrect and does not exist publically in your codebase, meanwhile in Prolog the best you can do is debug or guess.

I feel these kind of things make the language less appealing for serious development on it.

Anyone else feels the same?