Logtalk

Logtalk is an object-oriented logic programming language created by Paulo Moura and first released publicly in 1998. Rather than replacing Prolog, Logtalk extends it: a Logtalk program is compiled down to standard Prolog and runs on top of an existing Prolog system. The language adds the structuring tools that classic Prolog lacks — objects, interfaces, and composable components — while preserving Prolog’s declarative core, unification, and backtracking. The result is a language that brings encapsulation, modularity, and code reuse to logic programming without abandoning what makes Prolog distinctive.

History and Origins

Logtalk was designed by Paulo Moura, a Portuguese computer scientist. An early experimental system bearing the Logtalk name appeared in 1995 as an exploration of computational reflection, but the modern language proper dates to 1998: development began in January of that year, with the first public alpha released in July and the first stable release, Logtalk 2.0, following in February 1999. The motivation was practical. Prolog is a powerful declarative language, but traditional Prolog offers limited facilities for programming in the large: predicates live in a mostly flat namespace, there is no portable, standardized notion of an interface or module across implementations, and reuse tends to rely on copy-and-paste or implementation-specific module systems.

Moura set out to give Prolog programmers the organizational tools that object-oriented languages had popularized — encapsulation, inheritance, and separation of interface from implementation — while remaining faithful to logic programming semantics. Crucially, Logtalk was built as a portable layer that sits on top of standard, ISO-compliant Prolog systems rather than as a brand-new interpreter. This decision let Logtalk benefit from the performance and ecosystems of mature Prolog engines while focusing its own development on the object model.

The language went through a long and active 2.x series before a major redesign culminated in Logtalk 3.0, released in January 2015. Logtalk 3 rewrote much of the compiler and runtime, tightened standards compliance, and improved tooling, and it remains the line under active development today.

Design Philosophy

Logtalk’s central idea is that logic programming and object-oriented programming are complementary rather than opposed. Its design rests on a few guiding principles:

• Extend, don’t replace. Logtalk is a superset of much of standard Prolog. Existing Prolog code and idioms continue to work, and Logtalk objects can call plain Prolog predicates. Programmers adopt the object features incrementally.
• Portability across backends. A core goal is running the same Logtalk code on many different Prolog systems. This insulates applications from any single vendor and lets developers choose a backend for performance, licensing, or platform reasons.
• Fine-grained reuse. Beyond simple inheritance, Logtalk separates the what (protocols) from the how (objects) and offers categories as independently testable, composable building blocks.
• First-class declarative semantics. Message sending, inheritance lookup, and event handling are all defined in a way consistent with Prolog’s resolution model.

Key Features

Logtalk’s object model is built from three kinds of first-class code units:

• Objects — the primary unit of encapsulation. Logtalk supports both prototype-based objects (objects that extend other objects directly, à la Self or JavaScript) and class-based hierarchies (with instances and metaclasses, closer to Smalltalk). The two styles can coexist in the same program.
• Protocols — named, standalone interfaces that declare predicates without implementing them. Protocols play the role of interfaces in Java or protocols in Objective-C, allowing contracts to be defined and implemented independently.
• Categories — fine-grained, composable units of code that can be imported by multiple objects. Categories enable a form of composition and code sharing that is orthogonal to inheritance, similar in spirit to traits or mixins.

On top of these, Logtalk provides:

• Multiple inheritance for both protocols and objects, with predictable lookup semantics.
• Parametric objects, whose identity includes logic-variable parameters — a natural fit for logic programming.
• High-order programming and lambda expressions, extending Prolog’s meta-predicate style with cleaner, more explicit syntax.
• Event-driven programming, where messages can trigger before and after events, supporting reflective and aspect-like patterns.
• Separation of interface and implementation, encouraging designs where protocols are stable contracts and objects supply the logic.

A small example shows the flavor of an object that implements a protocol:

:- protocol(greeting).
    :- public(hello/0).
:- end_protocol.

:- object(world,
    implements(greeting)).
    hello :- write('Hello, World!'), nl.
:- end_object.

Sending the hello message is then written as world::hello.

Portability and Backends

One of Logtalk’s defining characteristics is that it does not ship its own Prolog engine. Instead, it runs on top of a wide range of standard-compliant Prolog systems. Over its history it has supported many backends, including SWI-Prolog, YAP, GNU Prolog, SICStus Prolog, ECLiPSe, and XSB, and more recently newer systems such as Trealla Prolog and Scryer Prolog. The exact set of supported and recommended backends changes over time; the official documentation maintains the authoritative, up-to-date compatibility list. Because Logtalk leans on the host system for execution, available platform support (operating systems and architectures) largely follows that of the chosen Prolog backend rather than being a property of Logtalk itself.

Evolution

The 2.x series, which spanned roughly from the first stable release in 1999 through the early 2010s, established Logtalk’s object model and steadily added capabilities such as parametric objects, lambda expressions, and multi-threading support. Work on a third generation began in 2012, and Logtalk 3.0 was released on January 7, 2015. It was a substantial reengineering that improved compliance with the ISO Prolog standard, refined the module and object semantics, sped up compilation and execution, and modernized the developer experience.

Beginning with version 3.01.0 in 2015, Logtalk has been distributed under the Apache License 2.0 — a permissive license that eased adoption in both commercial and academic contexts — replacing the Artistic License 2.0 used for the 2.x line. Development has remained notably active, with frequent point releases that track new Prolog systems, add library functionality, and refine the toolchain. The distribution bundles a rich portable standard library and developer tools — including support for automatically generating documentation, running unit tests, and producing diagrams — many of which are themselves written in Logtalk.

Current Relevance

Logtalk occupies a focused niche: it is the most prominent and mature object-oriented extension of Prolog. For developers building substantial Prolog applications, it offers a disciplined way to manage complexity that flat Prolog does not provide, and its portability means projects are not locked to a single Prolog vendor. In education, it is valued for letting students explore logic programming and object-oriented design within a single coherent system. It continues to be maintained by its original author and a community of contributors, and it tracks developments in the broader Prolog world by adding support for emerging engines.

It is not a mainstream language and never aimed to be. Its audience is the logic programming community and researchers and engineers who want the expressive power of Prolog combined with modern structuring mechanisms.

Why It Matters

Logtalk is a careful, long-running demonstration that paradigms can be combined without diluting either one. It showed that Prolog could gain genuine object-oriented abstractions — encapsulation, interfaces, composition, and inheritance — while keeping its declarative semantics intact, and that such a layer could be made portable across many independent Prolog implementations. For the logic programming community it provided practical answers to long-standing questions about programming in the large, and for the wider field it stands as a thoughtful case study in language design as careful extension rather than reinvention.