Umfang

Dieses Thema kann als Bachelorarbeit oder Teil einer Projektarbeit bearbeitet werden.

Empfohlene Vorkenntnisse

  • Kenntnisse von Prolog (z.B. durch Besuch der Veranstaltung “Einführung in die logische Programmierung”)

Problem

Prolog Prädikate beschreiben Zusammenhänge zwischen ihren Argumenten mittels Logik, so dass es keine zwingende Unterscheidung zwischen Ein- und Ausgabewerten gibt. Ein Prädikat wird demnach entweder als wahr oder falsch interpretiert und hat keinen Rückgabewert wie man es zum Beispiel aus der funktionalen Programmierung kennt.

Das Debugging in Prolog gestaltet sich für komplexe Programme oftmals schwierig, da unter Umständen nur ein “no” bzw. “false” von dem Prolog Interpreter zurück geliefert wird. Das übliche Vorgehen ist es dann mittels Tracing den Verlauf einer Anfrage an den Prolog Interpreter zu verfolgen und letztlich manuell den Grund für das fehlschlagen eines Prädikats zu ermitteln. Je nach Anzahl der Argumente eines Prädikats und der verwendeten Datenstrukturen kann dies schnell unübersichtlich und mühsam werden.

Eine Anfrage an den Prolog Interpreter (Goal) besteht in den meisten Fällen aus einer Reihe an Sub-Goals, welche individuell erfolgreich oder fehlgeschlagen sein können. Innerhalb dieser Reihe von Anfragen befinden sich eine oder mehrere fehlerhafte Anfragen, welche lokalisiert werden sollen. Hierbei kann das Wissen genutzt werden, dass Prolog Prädikate deklarativ beschreiben was berechnet wird und nicht zwingend explizit vorgeben wie etwas berechnet wird (vgl. imperative Programmierung). Die Idee ist es nun einen unterstützenden deklarativen Debugger für SWI- und/oder SICStus-Prolog zu entwickeln, welcher zum Beispiel die folgenden Features bietet:

  • vergleiche Teilergebnisse mit dem vom Entwickler geforderten Verhalten, welches aus Prolog Prädikaten extrahiert werden kann
  • stelle dem Benutzer Fragen in Form von Sub-Goals, welche abwechselnd vom Anfang und Ende der Liste an Sub-Goals geholt werden, so dass letztlich die genaue Fehlerursache lokalisiert werden kann (eine Art Bisektion)
  • da diese Fragen an den Benutzer je nach Größe der Argumente unübersichtlich sein können, soll es möglich sein während dem Debugging beliebige Prädikate auf gewisse Argumente anzuwenden, welche Informationen von Interesse aus Daten extrahieren oder transformieren (im Falle eines abstrakten Syntaxbaum könnte dies zum Beispiel ein Pretty-Printer sein)

Im Rahmen der Vorbereitung zur Arbeit werden ggf. weitere Anforderungen herausgearbeitet.

Einige Referenzen für mögliche Erweiterungen sind zum Beispiel hier zu finden (Lee Naish et al.).

Kontakt

Joshua Schmidt
Raum 25.12.02.52 · joshua.schmidt@hhu.de