Prolog-Entwicklung: Vier Fehler, die Programme zum Scheitern bringen

Prolog hat etwas Rebellisches. Während die meisten Entwickler bei imperativen oder objektorientierten Sprachen bleiben, wählen Prolog-Programmierer einen anderen Weg. Sie arbeiten mit deklarativer Logik – und das fühlt sich oft befriedigend an. Bis es nicht mehr funktioniert.

Dabei reichen ein paar grundlegende Regeln, um Prolog-Code stabil und wartbar zu machen. Wer sie verletzt, riskiert, dass Programme falsche Ergebnisse liefern, Lösungen übersehen oder sich kaum noch testen lassen. Hier sind die vier typischen Stolpersteine.

Zu viel Vertrauen in unsaubere Konstrukte

Man schreibt eine Regel, testet sie mit festen Werten – und sie funktioniert. Doch sobald jemand eine allgemeinere Abfrage stellt, bleibt die Antwort aus. Das passiert häufig durch den Einsatz von Cut (!), If-Then-Else und Prädikaten wie var/1. Diese Konstrukte machen den Code zwar kürzer, brechen aber die deklarative Natur von Prolog.

% Unsauber: Cut blockiert weitere Lösungen
factorial(0, 1) :- !.
factorial(N, F) :-
    N > 0,
    N1 is N - 1,
    factorial(N1, F1),
    F is N * F1.

Wird factorial(N, F) ohne feste Werte aufgerufen, kommt nur noch die erste Lösung zurück. Alle weiteren bleiben verborgen. Sauberer ist es, mit dif/2 und Meta-Prädikaten zu arbeiten. Der Code bleibt dann allgemeiner und besser testbar.

Dynamische Datenbank als versteckte Abhängigkeit

Viele Entwickler entdecken früh assertz/1 und retract/1. Damit lässt sich die Wissensbasis zur Laufzeit ändern – gefühlt eine mächtige Möglichkeit. Doch wer damit arbeitet, baut unsichtbare Verbindungen auf.

Der Zustand wandert nicht mehr klar sichtbar durch die Argumente,而是隐藏在全局数据库中。测试变得困难，因为每个测试可能留下残留物。最好是把状态 explizit durch Argumente oder Kontextnotationen führen.

Logik und Ausgabe vermischen

Auch erfahrene Entwickler fallen manchmal darauf rein:

% Anti-Pattern: Ausgabe direkt im Prädikat
solve_and_print :-
    solution(S),
    format("The solution is: ~q~n", [S]).

Das Prädikat lässt sich kaum testen oder wiederverwenden. Die Ausgabe erscheint nur auf dem Terminal – als Prolog-Term lässt sich die Lösung nicht weiterverarbeiten. Besser ist es, die Lösung rein logisch zu beschreiben und die Aufbereitung an eine höhere Ebene zu übergeben. Mit DCG-Notation lässt sich die Formatierung ebenfalls deklarativ halten.

Veraltete Arithmetik statt moderner Constraints

Prolog hat sich weiterentwickelt. Seit Jahren existieren Constraint-Logikprogrammierung über Finite Domains (CLP(FD)) und andere High-Level-Werkzeuge. Doch manche Entwickler halten noch immer an (is)/2, (=:=)/2 und (>)/2 fest.

Der Effekt ist deutlich: Der Code wirkt weniger klar, ist schwerer zu lehren und zu verstehen. Mit CLP(FD) dagegen bleibt die deklarative Absicht erhalten. Der Code liest sich wie eine Spezifikation, nicht wie eine Prozedur.

Beispiel: Die Horror-Factorial

% Problemversion
horror_factorial(0, 1) :- !.
horror_factorial(N, F) :-
    N > 0,
    N1 is N - 1,
    horror_factorial(N1, F1),
    F is N * F1.

Dieser Code verstößt gegen drei Prinzipien zugleich. Der Cut verhindert weiteres Backtracking, die Low-Level-Arithmetik erzwingt korrekt eingetragene Werte und die Generalität fehlt. Wer jetzt ?- horror_factorial(N, F) abfragt, erhält nur noch eine Lösung und danach nichts mehr.

Wie guter Prolog-Code aussieht

Guter Prolog-Code folgt wenigen Regeln:

• Deklarative Muster bevorzugen – Constraints und Meta-Prädikate statt Cuts und Typ-Checks.
• Zustand sichtbar halten – Explizit durch Argumente oder Kontext-Notationen führen.
• Logik von Ausgabe trennen – Lösungen rein beschreiben, Aufbereitung an die oberste Ebene delegieren。
• Moderne Werkzeuge nutzen – CLP(FD) und ähnliche High-Level-Ansätze sind meist besser.

Wer diese Grundsätze einhält, schreibt Prolog-Code, der auch bei allgemeinen Abfragen zuverlässig arbeitet. Er liest sich dann wie eine Spezifikation und bleibt langfrist