In the landscape of programming languages, special info few are as distinctive as Icon. Born in the late 1970s at the University of Arizona under the guidance of Ralph Griswold, Icon was designed with a radical philosophy: programming should be about expressing what you want to achieve, not how to achieve it. Its crown jewel is goal-directed evaluation, a built-in mechanism where expressions don’t just compute values—they search for them. Coupled with powerful string scanning and a rich set of data structures, Icon became a favorite for text processing, scripting, and rapid prototyping. Yet, as software engineering moved toward larger systems, encapsulation, and component reuse, Icon’s procedural core began to show its age. Enter Unicon—a bold extension that grafts object-oriented programming onto this goal-directed foundation, creating a hybrid language that marries expressive power with modern software architecture.
The Iconic Foundation: Success, Failure, and Search
To appreciate Unicon’s OOP extension, one must first understand Icon’s unique evaluation model. In most languages, an expression either computes a value or throws an error. In Icon, every expression either succeeds and produces a value, or it fails. Failure is not an exception; it is a signal that drives backtracking.
Consider a simple comparison: in C or Python, a > b returns a boolean. In Icon, a > b succeeds and returns b if a is indeed greater; otherwise, it fails. This success-or-failure semantics is woven into control structures. The alternation operator |, for instance, tries its left operand; if that fails, it tries the right. This creates a generative, search-like behavior.
A classic example is finding a vowel in a string:
text
if find("a", s) | find("e", s) | find("i", s) then
write("Found a vowel")
Each find call is attempted in sequence; the first success short-circuits the expression. This is not just syntactic sugar—it fundamentally changes how you think about control flow. Loops, conditionals, and even assignment can be backtracked into, allowing the language to solve combinatorial problems with minimal code. Icon’s every loop, for example, iterates over all successful results of a generator:
text
every write(find("a", "banana"))
This prints 2, 4, and 6—every position where “a” occurs.
The Gap: Why OOP?
Despite its elegance, Icon was designed in an era when procedural programming dominated. Its type system is rich—lists, sets, tables (associative arrays), records—but there is no native mechanism for bundling data with behavior, no inheritance, and no polymorphism beyond operator overloading. For small-to-medium scripts, this is fine. But when building graphical user interfaces, network services, or large simulations, the lack of encapsulation becomes a strain.
Icon’s records offered a partial solution: they define named fields, and you can assign procedures to those fields. But this is manual, error-prone, and lacks any formal notion of classes or inheritance. Method dispatch must be done by hand:
text
record Point(x, y)
procedure move(p, dx, dy)
p.x +:= dx
p.y +:= dy
end
Calling p.move(dx, dy) is not possible; you write move(p, dx, dy) instead. This breaks encapsulation and makes polymorphic code cumbersome. As the Unicon project took shape, led by Clint Jeffery and a team at the University of Idaho, the mission became clear: add first-class OOP support without sacrificing the goal-directed soul of Icon.
Unicon’s Approach: Classes as Generators
Unicon, which stands for “Unified Extended Dialect of Icon,” introduces a robust class model. At its core, a Unicon class is a template that bundles mutable state (attributes) with methods. But in a stroke of design genius, Unicon treats classes not just as blueprints, but as integrated into the success/failure evaluation model. Methods can be generators, methods can fail, and object instantiation can be goal-directed.
A simple class in Unicon looks like this:
text
class Counter(filename)
method init
self.count := 0
end
method bump()
self.count +:= 1
return self.count
end
method reset()
self.count := 0
end
end
The init method is the constructor, see this website automatically called when an object is created with Counter(). The self keyword provides access to the instance’s attributes. The syntax is clean, reminiscent of a modern dynamic language like Python or Ruby, but the semantics beneath are pure Icon.
Crucially, methods participate in goal-directed evaluation. If a method fails, it signals its caller, which can trigger backtracking. This is not a mere implementation detail—it is a compositional superpower. You can write a method that generates multiple results:
text
class Directory
method files()
every suspend !self.filelist
end
end
Here, suspend yields a value while keeping the method’s state, so calling code can iterate over files() using Icon’s every loop. The method is a generator, blending OOP with Icon’s backtracking seamlessly.
Inheritance and Polymorphism
Unicon supports single inheritance with a straightforward syntax:
text
class BoundedCounter : Counter(limit)
method init
Counter.init() # call superclass constructor
self.limit := limit
end
method bump()
if self.count < self.limit then
return Counter.bump()
else
fail
end
end
The colon denotes inheritance, and parameters can be passed to the superclass. The init method explicitly chains to the parent constructor, ensuring proper initialization. In bump(), the method overrides the parent’s version but can still invoke it via Counter.bump(). If the counter hits its limit, the method deliberately fails. This failure propagates, and any caller using goal-directed evaluation can react accordingly—perhaps by trying an alternative BoundedCounter or resetting and retrying.
Polymorphism arises naturally. If a variable holds an object, method dispatch uses the dynamic type, not the static declaration. A procedure that expects a Counter will work perfectly with a BoundedCounter because the latter’s bump() method adheres to the success/failure contract. This is the essence of Liskov substitution, and Unicon supports it by default.
Packages and Large-Scale Structure
Beyond classes, Unicon introduces a module system via packages. A package is a collection of classes and procedures that can be imported and linked. This addresses another historical limitation of Icon, which had no standard way to organize large codebases. Packages encourage encapsulation at a higher level, allowing developers to create reusable libraries with clear interfaces.
For example, a GUI package in Unicon wraps platform-specific toolkits, providing classes like Window, Button, and Canvas. These classes encapsulate low-level details, while inheritance allows developers to create custom widgets. The Unicon IDE itself, built in Unicon, stands as a testament to the language’s ability to handle large, interactive applications.
The Design Tension: Purity vs. Practicality
Adding OOP to a language as semantically pure as Icon was not without controversy. Some purists argued that goal-directed evaluation already provided a unifying abstraction, and that classes were unnecessary. After all, Icon’s tables and co-expressions (closures) could simulate objects, albeit awkwardly. The Unicon team, however, recognized that syntactic and structural support for classes is not just about what can be computed—it’s about how programmers model problems. OOP is a cognitive tool as much as a computational one.
The beauty of Unicon’s implementation is that it preserves Icon’s core philosophy. There are no special “boolean” types; methods still succeed or fail. There is no abrupt shift to an exception model; failure remains the control mechanism. The language remains dynamically typed, with duck typing applying to both objects and built-in structures. The addition of classes feels less like an extension and more like a completion.
A Bridge Between Worlds
Unicon remains a niche language, but its design lessons are universal. It demonstrates that goal-directed evaluation and object-oriented programming are not adversaries but allies. Generators and backtracking offer a declarative flavor that can simplify complex logic, while classes provide the structure needed for modern software. In an era where functional programming’s immutability and reactive streams dominate academic discourse, Unicon stands as a reminder that other paradigms—goal-directed, generative, backtracking—still have untapped potential.
For the programmer weary of boilerplate and eager to think in terms of success and failure, search and solution, Unicon offers a unique playground. It is a language where you can write a class that not only stores data but searches for answers, where failure is not an error but a path to another possibility. In extending Icon with OOP, Unicon has not diluted its ancestor’s vision; why not check here it has given it new life for a new generation of problems.