Simple Restarts: Hinter den Kulissen
Im vorherigen Blogpost haben wir Conditional Restarts in Clojure kennen gelernt und dabei die Bibliothek „Simple Restarts“ verwendet. Diese Bibliothek wurde als Anschauungsbeispiel erstellt, um Conditional Restarts in Clojure zu erklären. In diesem Blogpost werden wir einen Blick hinter die Kulissen werfen und verstehen, wie die Magie hinter „Simple Restarts“ implementiert ist: Eine lehrreiche Reise voller Illusion, Überraschungen und „Aha!“s.
Voraussetzungen
Neben guten Kenntnissen in Clojure, sollte der Leser die Einführung zu Conditional Restarts, die auf „Simple Restarts“ aufbaut, gelesen haben. Außerdem ist unsere Blogreihe zu Makros in Clojure sehr zu empfehlen, da ein großer Teil der Bibliothek mithilfe von Makros implementiert wurde. Insbesondere der dritte Teil der Serie ist wichtig, denn neben Makros kommen auch Records aus Active Clojure zum Einsatz, um zusammengesetzte Daten zu beschreiben.
Den Call-Stack hinauf und wieder hinunter
Conditional Restarts ermöglichen das Zusammenspiel von Restarts und Handlern und das Auslösen von Conditions über mehrere Funktionsaufrufe hinweg. Daher werden wir zunächst den Call-Stack genauer betrachten und verstehen, wie dieser funktioniert, um dann Conditional Restarts zu begreifen.
Wird eine Funktion aufgerufen, legt ein Prozessor oder eine virtuelle Maschine ein Frame auf den Call-Stack. Dieser Frame beinhaltet unter anderem die Argumente der Funktion, aber auch andere wichtige Informationen. Ruft die aufgerufene Funktion wiederum eine weitere Funktion auf, wird der Vorgang wiederholt, der Stack wächst. Ist eine Funktion abgearbeitet, wird sie vom Stack entfernt und die Berechnungen werden nach der Stelle fortgesetzt, an der der Frame auf den Stack gelegt wurde.
Historisch bedingt wächst der Call-Stack nach unten:
Wird foo aufgerufen und somit bar, liegen beide Funktionen auf dem
Stack (b). Durch die Auswertung von bar kommt baz hinzu (c), das nach vollständiger
Auswertung wieder entfernt wird (d).
Doch was hat dies mit Conditional Restarts zu tun? Um im Falle einer Condition
den passenden Restart zu finden, müssen wir im Stack zurück und sukzessive in den
vorherigen Frames nach dem ersten passenden Restart suchen. Nehmen wir an, dass
foo, bar und baz mit folgendem Inhalt, unter Zuhilfenahme von „Simple
Restarts“, gefüllt sind:
(defcondition example-condition [a b c])
(defn baz []
(raise-condition (example-condition 1 2 3)))
(defn bar []
(restart-case
(baz)
(restart :my-restart identity)))
(defn foo []
(handler-bind
[example-condition (fn [a b c] (invoke-restart :my-restart [a b c]))]
(bar)))
(foo)Es muss nun möglich sein, die Ausführung von baz zu unterbrechen und im Stack
rückwärts in bar nach passenden Restarts suchen. Ebenso müssen wir aber dafür
sorgen, dass der Handler, der in foo angibt, welcher Restart ausgelöst wird, in den
tieferen Stack-Frames (Aufruf von baz) bekannt ist.
Wir benötigen also die Möglichkeit, Informationen in tiefere Stack-Frames zu reichen, aber auch die, wieder zurückzuspringen. Clojure bietet zwei Mechanismen, die das ermöglichen: Bindings und Exceptions. Zudem verwenden wir Makros, um die Illusion perfekt zu machen.
Binden der Handler
Bevor es so richtig losgeht, implementieren wir ein Makro, um Conditions zu
definieren. Um eine Condition zu beschreiben, führen wir einen Record mit den
Feldern identifier und parameters ein. In dem Makro zur Definition einer
Condition defcondition definieren wir einfach eine Funktion, die den Namen des
Identifiers trägt und die Parameter entgegen nimmt:
(rec/define-record-type Condition
(make-condition identifer params) condition?
[identifer condition-identifier
params condition-params])
(defmacro defcondition [name params]
`(defn ~name ~params
(make-condition ~name ~params)))
;; Erstellen einer Condition
(defcondition example-condition [a b c])Wird also (example-condition 1 2 3) aufgerufen, wird ein Record erzeugt, welcher
das definierte Symbol example-condition der Funktion selbst als Identifier beinhaltet,
sowie den Vektor [1 2 3] im Feld condition-params. Durch das Macro ist es
möglich, eine Definition zu erzeugen, die Implementierungsdetails verbirgt.
Diese Condition kann in der Bibliothek dazu verwendet werden, Handler zu binden:
(handler-bind
[example-condition (fn [a] (invoke-restart :my-restart a))]
;; Code für den die Bindung des Handler gelten soll:
...
)Um dieses Makro zu implementieren, verwenden wir Clojure-Bindings in Verbindung mit dynamischen Variablen. Diese erlauben es uns, Variablen neu zu binden (pro Thread). Die Idee ist, eine Map von aktuell gültigen Handlern mitzuführen:
(def ^:dynamic *handlers* {})
(defmacro handler-bind [bindings & body]
(assert (even? (count bindings)))
`(binding [*handlers* (apply assoc *handlers* ~bindings)]
~@body))Mit der eingebauten Funktion binding fügen wir die an handler-bind
übergebenen Condition-Handler-Paare in die dynamischen Map *handlers* ein. Die
Map verwendet die durch die Condition-Definitionen definierten Funktionen als
Schlüssel, die Werte sind die Handler-Funktionen, die im Vektor jeweils an
gerader Stelle stehen. Wir verwenden hier ein Makro, da in body beliebiger
Code stehen kann, der vorerst nicht ausgeführt wird. Wie die Funktion
invoke-restart implementiert ist, erfahren wir später.
Conditions abfeuern
Sind die Handler erstmal in tieferen Stackframes sichtbar, kann das Feuerwerk
beginnen: Conditions können ausgelöst, vom Handler bearbeitet und
Exceptions geworfen werden, um in höheren Stackframes zu einem passenden Restart
zu gelangen. Wir implementieren die Funktion fire-condition, die eine Instanz
einer Condition entgegennimmt und eine Funktion condition-handler, die
verwendet wird, um aus der dynamischen Map den passenden Handler auszuwählen.
(def exception-identifier ::restart-invocation)
(defn condition-handler [name]
(if-let [handler (get *handlers* name)]
handler
(throw (ex-info "No handler found" {:condition name}))))
(defn fire-condition [condition]
(let [handler (-> condition condition-identifier condition-handler)
params (condition-params condition)
handler-result (apply handler params)]
(if (restart-invocation? handler-result)
(throw (ex-info "" {:type exception-identifier
:handler-result handler-result}))
(throw (ex-info "No restart invocation returned" {:handler handler})))))In fire-condition wird also mithilfe des Condition-Identifiers der passende
Handler ausgwählt und dieser anhand der Condition-Parameter ausgewertet. Handler
müssen stets eine Restart-Invocation (siehe folgenden Abschnitt) zurückgeben.
Die Funktion lässt im nächsten Schritt eine Exception fallen, die diese
Restart-Invocation beinhaltet und vom Typ ::restart-invocation ist.
Restart und Restart-Invocation
Sowohl Restarts also auch Restart-Invocations sind lediglich Daten:
(rec/define-record-type Restart
(restart n invocation-function) restart?
[n restart-name
invocation-function restart-invocation-function])
(rec/define-record-type RestartInvocation
(make-restart-invocation restart-name params) restart-invocation?
[restart-name restart-invocation-restart-name
params restart-invocation-params])
(defn invoke-restart [sym & params]
(make-restart-invocation sym params))Ein Restart besteht aus einem Namen für den Restart und einer Funktion für den Wiedereinstieg. Eine Restart-Invocation dagegen beinhaltet den Namen des auszulösenden Restarts, sowie einer Liste von Parametern für die Funktion für den Wiedereinstieg.
Restarts können anhand der Bibliothek folgendermaßen in den Code eingehängt werden:
(restart-case
;; do something here, e.g
(fire-condition (example-condition 1 2 3))
(restart :my-restart-1
(fn [baz] ...))
(restart :my-restart-2
(fn [buzz] ...)))restart-case nimmt einen Ausdruck entgegen, der ausgewertet werden soll und
eine Liste von Restarts, die im Falle einer Condition für diesen Ausdruck gelten
sollen. Da das Auslösen einer Condition über Exceptions den Stack aufwärts
kommuniziert, fangen wir diese im Makro auf:
(defn restart-invocation-exception? [e]
(= (:type (ex-data e)) exception-identifier))
(defn find-restart [restarts name]
(first (filter (fn [restart] (= (restart-name restart) name)) restarts)))
(defn restart-case-catch [e available-restarts]
(if (restart-invocation-exception? e)
(let [handler-result (:handler-result (ex-data e))
restart-name (restart-invocation-restart-name handler-result)
restart-params (restart-invocation-params handler-result)]
(if-let [restart (find-restart available-restarts restart-name)]
(apply (restart-invocation-function restart) restart-params)
(throw e)))
(throw e)))
(defmacro restart-case [body & restarts]
`(try
~body
(catch Exception e#
(restart-case-catch e# ~(vec restarts)))))
Die Magie passiert in der Funktion restart-case-catch: Diese überprüft zuerst,
ob es sich um die gewünschte Exception handelt—ansonsten wird die Exception
einfach erneut geworfen. Im Falle einer Restart-Invocation-Exception wird der
Name und die Parameter des auszulösenden Restarts aus der Restart-Invocation
extrahiert und der passende Restart aus der Liste der übergebenen Restarts gesucht.
Existiert kein passender Restart, wird die Exception erneut geworfen. Es kann ja sein, dass ein passender Restart in höheren Stack-Frames definiert wurde. Findet sich ein solcher Restart, wird die Wiedereinstiegsfunktion ausgewertet—und fertig ist das Kunststück.
Fazit
In diesem Blogpost haben wir die Tricks, die hinter der „Simple Restarts“-Bibliothek stehen, nachvollzogen. Es wurde gezeigt, wie die zwei Mechanismen, Bindings und Exceptions, verwendet werden, um bidirektional über den Stack hinweg zu kommunizieren. Makros helfen dabei, wie Illusionen, über die eigentlichen Vorgänge hinwegzutäuschen und ermöglichen es dem Anwender der Bibliothek ohne Verständnis der Interna, Sachverhalte abzubilden—wir Informatiker nennen dies Abstraktion. Lisps und ihr mächtiges Makrosystem erleichtern die Implementierung solcher Bibliotheken enorm.
Die Bibliothek hat auch Schwächen: Neben Fehlerbehandlung lässt sich die Verwendung von Exceptions nicht vollständig vor dem Anwender verbergen: Fängt dieser an einer Stelle alle Exceptions ab, funktioniert auch der Restart-Mechanismus nicht mehr. Dies könnte vom Anwender nicht gewollt sein und aus Unwissenheit über die Interna der Bibliothek passieren. Für Anschauungszwecke reicht der Exception-Mechanimus jedoch vollkommen.
Der vollständige Quelltext der Bibliothek ist auf GitHub verfügbar.
