0 Zusammenfassung

In dieser Arbeit geht es darum, den deklarativen Programmierstil zu untersuchen, weil er den Fokus darauf legt, dem Computer mitzuteilen, was gemacht werden soll, im Gegensatz zum imperativen Stil, bei dem es um das Wie geht.

Gerade heute beinhalten Programmiersprachen deklarative Elemente, wodurch mit ihnen produktiver gearbeitet werden kann. Eine moderne, multiparadigmatische Programmiersprache mit vielen deklarativen Elementen ist F#. Die Verwendung deklarativer Programmiersprachenelemente führt zu elegantem Quellcode und das damit oft assoziierte zustandslose Programmieren bringt insbesondere Vorteile bei parallelen Berechnungen. Dennoch müssen nicht alle Probleme zwingend zustandslos gelöst werden. Die Alternative, imperativ und zustandsorientiert zu programmieren, hat vor allem bei der Implementierung effizienter Algorithmen ihre Anwendung.

Ziel der Arbeit ist es, eine konkrete Idee von deklarativer Problemlösung zu vermitteln und die entgegengesetzten Programmierstile abzuwägen. Im Rahmen dieser Arbeit werden deklarative Programmiersprachenelemente von F# untersucht und ihren imperativen Pendants gegenübergestellt.

1 Einleitung

Diese Arbeit

Diese Arbeit stellt die deklarative Programmierung vor und vergleicht Konzepte aus diesem Programmierstil mit dem gegensätzlichen imperativen Paradigma. Letztendlich werden auch deklarative Programme auf einer niedrigen Maschinenebene umgesetzt, deshalb ist das Wissen um die Arbeitsweise deklarativer Sprachen eine Voraussetzung, um moderne Programmiersprachenfeatures zu bewerten und ihre Verwendung abzuwägen. Diese Arbeit ist aber keine Auflistung von beliebigen Programmiersprachenfeatures. Geeignete Modularisierung und hohes Abstraktionsniveau sind die zwei Kernanforderungen, die an eine Programmiersprache gestellt werden sollten, daher werden sie als Leitlinie benutzt.

F# tritt in dieser Arbeit als Vertreter der modernen deklarativen Programmierung auf und orientiert sich an der ML-Familie (ML steht für meta language) und ist funktional geprägt.
Zuerst gehe ich auf Anfänge deklarativer Sprachen ein, weil heutige Programmiersprachenkonzepte auf Ideen alter Programmiersprachen basieren. Dann werden deklarative Ansätze in F# untersucht, um eine konkrete Idee von deklarativer Programmierung zu geben.

In der Einleitung werden zuerst verschiedene Erklärungen und Definitionen von deklarativer Programmierung vor- und gegenübergestellt. Daraus resultiert eine eigene Definition, die in der Arbeit als Leitfaden verwendet wird. Mit einem kurzen Überblick über verwendete Paradigmen und der Zielsetzung dieser Arbeit schließt das Kapitel.

Was ist deklarative Programmierung?

Definition nach [InformatikLexikon]:

deklarativ: Erklärend, verkündend; Programmiersprachen der 4. Generation; in einer d. Programmiersprache erklärt der Progammierer, was er erhalten oder erreichen möchte, aber die Einzelschritte zum Ziel entscheidet der Compiler oder Interpreter; man erklärt das Was, nicht aber das Wie; Abfragesprachen sind im Allgemeinen d., weil wir nur eine Datenmenge beschreiben: im Beispiel SELECT name FROM mitglieder übernimmt das System die Öffnung der Datei und/oder die Steuerung des Cursors durch alle Datensätze hindurch sowie Optimierungen u. a.; funktionale Programmiersprachen sind d., weil es in ihnen keine Anweisungen, sondern nur Funktionen gibt, vergleiche Lambda-Kalkül; siehe als Gegensatz: deskriptiv [InformatikLexikon, S. 215]
Nach [PractAdvantDecl]:

Informally, declarative programming involves stating what is to be computed, but not necessarily how it is to be computed. […] The key idea of declarative programming is that a program is a theory (in some suitable logic) and that computation is deduction from the theory. [PractAdvantDecl, S. 1]
Nach [DeklarativeProgrammierung]:

Gemeinsam ist allen deklarativen Sprachen, daß die Lösung eines Problems auf einer hohen Abstraktionsebene spezifiziert, und nicht auf einer niedrigen Maschinenebene ‚ausprogrammiert‘ wird.
Offensichtlich sind gemäß dieser Unterscheidung die Grenzen fließend!
Entscheidend ist hierbei, was wir als ‚high-level‘ vs. ‚low-level‘ bezeichnen. Gemeint ist in diesem Zusammenhang etwa nicht der Unterschied zwischen maschinennahen (Assembler-) und problemorientierten (‚höheren‘) Programmiersprachen.
[DeklarativeProgrammierung, S. 7]
Nach [MultiparadigmenProg]:

Die zustandsfreien Sprachen (auch oft deklarative Sprachen genannt) werden im Wesentlichen in funktionale, logische und constraint-basierte Programmiersprachen unterteilt. [MultiparadigmenProg, S. 8]

Folgende Eigenschaften und Ideen lassen sich extrahieren:

  • Was statt Wie (der Computer entscheidet die konkrete Umsetzung)
  • deklarative Programme sind zustandsfrei / referentiell transparent
  • Problem wird auf einer hohen Abstraktionsebene spezifiziert
  • funktionale, logische und constraint-basierte Programmiersprachen sind deklarativ

Insbesondere finde ich die Haltung des deklarativen Programmierers wichtig, d.h. Konzentration auf das Problem, nicht auf die Umsetzung auf Maschinenebene. Für diese Arbeit schlage ich deshalb eine eigene, kurze Formulierung vor, welche die Tätigkeit des Programmierers beschreibt, ohne mich dabei auf Programmiersprachfamilien einzuschränken. So können auch domänenspezifische Sprachen und geeignete Konzepte aus imperativ-objektorientierten Programmiersprachen deklarativ genannt werden.

Deklarative Programmierung ist das Formulieren von Regeln und Zusammenhängen, die in ein ausführbares Programm überführt werden können.

Die Kernpunkte dieser Definition werden hier einmal aufgeschlüsselt:

  • Das Formulieren geschieht üblicherweise durch das Schreiben von Text oder Quelltext, aber auch grafische Symbolmanipulation ist denkbar.
  • Regeln beschreiben Bedingungen, um Fälle zu klassifizieren oder zu behandeln.
  • Zusammenhänge sind z.B. funktionale Zusammenhänge oder logische Relationen.
  • Ein ausführbares Programm ist entweder eine fertige Anwendung oder ein Programmbaustein, der in einer anderen Anwendung benutzt wird.
  • Überführt werden die Beschreibungen in ausführbare Programme z.B. durch Codegenerierung und Kompilierung oder Programmtransformation und -Interpretation.

Obwohl Definitionen wie a program is a theory (in some suitable logic) and […] computation is deduction from the theory [PractAdvantDecl] der deklarativen Idee recht nahe kommen, halte ich es dennoch für wichtig genug, zwei zentrale Elemente der Programmierung in den Vordergrund zu stellen: Regeln zur Unterscheidung und Zusammenhänge zur Berechnung. Insbesondere da gängige Programmierung bisher noch mit Quellcode und (noch) nicht mit Formeln aus der Mathematik funktioniert.

Wozu deklarative Programmierung?

Bei deklarativer Programmierung konzentriert man sich auf die wesentliche Problemlösung und nicht auf Details der Umsetzung.
  • Problemlösung ist der Zweck von Programmen.
  • Details der Umsetzung lenken von der Problemlösung ab und können komplex (z.B. Speicherhierarchie), fehlerträchtig (z.B. Speicherfreigabe) oder lästig (z.B. Datenprüfung) sein.
    Bei der Arbeit mit solchen Details kann fehlende Programmierdisziplin oder Unwissen zu fatalen Fehlern führen. Unterstützt eine Programmiersprache nicht die nötige Modularisierung, sind einfache Aufgaben nur durch Schreiben von sogenanntem Boilerplate-Code (größere Quellcode-Ausschnitte, die geringfügig abgeändert an mehreren Stellen auftreten) zu lösen [RealWorldFP, vgl. S. 130].

Imperative Programmierung

Der Gegensatz von deklarativer Programmierung ist imperative Programmierung (auch deskriptive oder prozedurale Programmierung [InformatikLexikon]). Die Kernidee imperativer Programmierung ist es, den Zustand während des Programmablaufs durch die Ausführung von Anweisungen zu verändern, sodass das Ziel erreicht wird. Durch die aus der prozeduralen Programmierung ermöglichten Prozeduren kann Quellcode organisiert werden, was Programmbibliotheken und Unterprogramme ermöglicht [MultiparadigmenProg, vgl. S. 11-12].
Imperative Programmierung ist wichtig, weil sie mit der Arbeitsweise des Computers übereinstimmt und gängige Algorithmen, die in Pseudocode notiert sind, sich auf imperative Programmierung berufen.

Objektorientierung

Ein besonders wichtiges Programmier-Paradigma der heutigen Zeit ist Objektorientierung (kurz OO). Der wichtigste Vertreter in der Anfangszeit dieses Paradigmas ist die Programmiersprache Smalltalk. Die zentrale Idee ist die Strukturierung von Programmen durch Klassen und Organisierung von Programmlogik durch Methoden. Viele heutige Frameworks basieren auf diesem Paradigma und es ist Teil des Lehrplans vieler Schulen und Universitäten. Die bekanntesten Vertreter des objektorientierten Paradigmas sind Java, C# und C++ [InformatikLexikon, vgl. S. 701].

Beim objektorientierten Entwurf wird oft UML (Unified Modeling Language) verwendet, eine grafische Beschreibungssprache zur Kommunikation von Zusammenhängen von Klassen und anderen Bausteinen. Es haben sich Entwurfsmuster aus zahlreichen objektorientierten Entwürfen herauskristallisiert, die in dem Buch [Entwurfsmuster] strukturiert dargestellt wurden. Diese Entwurfsmuster lösen häufig auftretende Probleme in objektorientierten Programmen, und gehören zum Handwerkszeug für OO-Programmierer. In anderen Programmierparadigmen können vergleichbare Probleme durch Konzepte des Paradigmas elegant gelöst werden. Eine Gegenüberstellung der objektorientierten Entwurfsmuster mit Konzepten des Funktionalen Paradigmas gibt [AnalyseEntwurfsmusterFP].

Aufbau dieser Arbeit

Als frühe Vertreter der deklarativen Programmierung werde ich Prolog und Miranda vorstellen.
Es folgt sodann ein Katalog der deklarativen Programmierung mit F#.
Im Kapitel Imperativer Stil werden einerseits einige imperative-objektorientierte Konzepte beleuchtet, insbesondere alternative Techniken und Herangehensweisen im Vergleich zum deklarativen Stil. Andererseits werden Vorteile imperativer Programmierung dem deklarativen Ansatz gegenüber gestellt und Kombinationsmöglichkeiten vorgestellt. So können aus beiden Denkweisen einige Vorteile vereint werden.
Ausführlicher werden Fallunterscheidungsmöglichkeiten aus beiden Paradigmen gegenübergestellt und verglichen. Dazu dient als Beispiel ein Code-Interpreter.
Ein Fazit schließt die Arbeit.

Zuvor habe eine Definition und Erklärung gegeben:

Deklarative Programmierung ist das Formulieren von Regeln und Zusammenhängen, die in ein ausführbares Programm überführt werden können.
Bei deklarativer Programmierung konzentriert man sich auf die wesentliche Problemlösung und nicht auf Details der Umsetzung.

Die beiden oben genannten Sätze lassen sich auch zu einem zusammenfassen:

Deklarative Programmierung ist das Formulieren von Regeln und Zusammenhängen, die in ein ausführbares Programm überführt werden können, wobei man sich auf die wesentliche Problemlösung und nicht auf Details der Umsetzung konzentriert.

Zwei Techniken außerhalb von Programmiersprachenkonzepten möchte ich auch behandeln: DSLs und Metaprogrammierung.
Zu deklarativen Sprachen zählt man auch domänenspezifische Sprachen (domain-specific languages, kurz DSLs), eingeschränkte fachspezifische Sprachen, die Vorzüge gegenüber generellen Programmiersprachen haben [DSLs, vgl. S. 33] und im gleichnamigen Abschnitt vorgestellt werden.
Metaprogrammierung ist einerseits eine Techniken-Sammlung für DSLs und andererseits werden dadurch Programmtransformationen möglich, die den deklarativen Horizont erweitern. Beispielsweise können Programmteile in F# geschrieben werden, die in Code einer anderen Programmiersprache transformiert werden. Dies ist Thema des gleichnamigen Kapitels.

2 Deklarativer Programmierstil um 1980

Der Begriff deklarative Programmierung wird ebenfalls als Sammelbegriff für funktionale, logikbasierte und constraintbasierte Programmierung verwendet [MultiparadigmenProg, vgl. S. 8].
Frühe Vertreter der deklarativen Programmierung sind LISP (1958), Miranda (1985) und Prolog (1972), sowie weniger bekannte Spezifikationssprachen, die jedoch im Allgemeinen nicht ausgeführt werden können und nur Beschränkungen formulieren [FPWithMiranda, vgl. S. 4]. Insbesondere ist der mit diesen genannten Sprachen verfolgte deklarative Ansatz ein völlig anderer als der Ansatz der imperativen Programmierung mit C-ähnlichen Sprachen.

Der deklarative Ansatz soll mit meiner Definition abgeglichen und anhand von Prolog und Miranda als alte deklarative Sprachen illustriert werden.


Eine wichtige Eigenschaft in diesem Zusammenhang ist die referenzielle Transparenz. Sie bedeutet, dass eine Funktion bei gleichen Argumenten immer denselben Wert produziert und der Wert nur von den Argumenten abhängig ist. Die Idee ist es, Gleiches mit Gleichem zu ersetzen; das heißt konkret, dass die Funktionsapplikation mit dem Ergebnis der Applikation ersetzt werden könnte. Diese Ersetzung nennt sich auch Auswertung oder Reduktion.

In [FPWithMiranda, S. 2] wird der Ausdruck (z.B. der arithmetische Ausdruck 2 * a + b * c) als Gemeinsamkeit aller deklarativen Sprachen genannt. Dieses Konstrukt taucht auch in der imperativen Programmierung oft auf. Es gibt aber Unterschiede – sogar innerhalb von deklarativen Sprachen:

  • Miranda und reine funktionale Programmiersprachen: keine Seiteneffekte und verzögerte Auswertung (laziness). Das Schreiben eines Ausdrucks führt dazu, dass gespeichert wird, wie das Ergebnis berechnet wird. Dies geschieht nur, wenn der Wert ausdrücklich für die weitere Berechnung benötigt wird.
  • Prolog: verzögerte Auswertung dank Strukturen. Das Schreiben eines Ausdrucks führt zur Konstruktion einer Struktur, d.h. eines Datenbehälters. Der Prolog-Ausdruck 1 + 2 * X ist lediglich eine Infix-Operator-Schreibweise der geschachtelten Struktur '+'(1, '*'(2, X)). Mithilfe des is-Prädikats kann der Wert berechnet werden. Arithmetik in Prolog wird dadurch erschwert und durch den relationalen Charakter müssen Rechenergebnisse an Parameter des Prädikats gebunden werden (anstatt wie in funktionalen Sprachen implizit einen Rückgabewert zu berechnen).
  • Funktionale Programmiersprachen ohne Laziness (z.B. F#): Arithmetik funktioniert intuitiv (wie in der Mathematik), evtl. muss aber auf Zahl-Typen geachtet werden (Ganz- und Gleitkommazahlen mit unterschiedlicher Genauigkeit) und Überläufe müssen behandelt werden.
  • Imperativ(-objektorientierte) Programmiersprachen (z.B. C#): Ausdrücke können nur an einigen Stellen stehen, etwa nach einem return, auf der rechten Seite einer Zuweisung oder in einer Argumentstelle eines Prozedur- bzw. Methodenaufrufs. Ansonsten verhalten sich Ausdrücke wie in funktionalen Programmiersprachen ohne Laziness.
Bearbeitet: Auf das deklarative Verarbeitungsmodell eingegangen.

Auch wenn es Unterschiede bei Ausdrücken in deklarativen Sprachen gibt, ist es ihnen gemeinsam, dass die Ermittlung des Ergebnisses (Auswertungsstrategie) eines solchen Ausdrucks vom System übernommen wird. Es wird nur das Ergebnis spezifiziert, weniger der Weg, um es zu berechnen. Bei einfachen Ausdrücken, mag dies auf imperative Programmiersprachen ebenfalls zutreffen, aber bei aufwendigeren Ausdrücken wie der Fakultätsvorschrift n! = \prod_{i=1}^n i, n > 0 zeigt sich der große Unterschied: Seq.reduce (*) {1..n} als deklarativer F#-Ausdruck und in C# als imperative Berechnungsvorschrift:

int prod = 1;
for(int i = 1; i <= n; i++) { prod *= i; }

In imperativen Programmiersprachen wird ein Prozess dargestellt, in deklarativen das Ergebnis formuliert.

Referenzielle Transparenz wird auch als Voraussetzung für deklarative Programmierung angesehen. Dies ist auf die Verwendung von deklarativer Programmierung als Sammelbegriff für funktionale, logikbasierte und Constraintprogrammierung zurückzuführen. Viele frühe Vertreter dieses Paradigmen wiesen referenzielle Transparenz auf. Dennoch sollten die Konzepte aus der funktionalen Programmierung nicht nur an referenzielle Transparenz gebunden sein und Zugriff auf veränderbare Daten haben. Dies ist in multiparadigmatischen Programmiersprachen der Fall und bringt Vorteile für die imperative und deklarative Welt.

Eine Abschwächung der referenziellen Transparenz ist die Verwendung veränderbarer Datenstrukturen innerhalb einer Funktion aus Effizienzgründen, sofern die veränderbaren Daten nur innerhalb der Funktion erzeugt und verändert wurden. Die entsprechende Funktion bleibt referenziell transparent. Das produzierte Ergebnis (z.B. ein Array) wird üblicherweise unter einer unveränderbaren Sicht (immutable-vector in Racket/Scheme) zurückgegeben, um den funktionalen Charakter weiterhin zu garantieren.

2.1 Prolog


Prolog ist eine deklarative Programmiersprache, die auf der Prädikatenlogik der ersten Stufe basiert und deren zentraler Mechanismus die Unifikation ist. Programmiert wird, indem in einer Wissensbasis (d.h. einer Datenbank) Prädikate mithilfe von Fakten und Regeln definiert werden, die in Abfragen (queries) benutzt werden können, um Informationen zu erhalten. Dazu wird vom System die Eingabe mit passenden Klauseln (Fakten oder Regeln) aus der Datenbank unifiziert und es werden Variablenbindungen ausgegeben. Der Unifikations-Mechanismus wird im Anschluss an die Beispiele erklärt.

Prolog ist ein hervorragendes Beispiel für den deklarativen Stil, weil hier nur das Was definiert werden kann. Zuweisung und Sprünge sind nicht möglich. Es wird stattdessen mit Variablenbindung, Rekursion und Backtracking gearbeitet. Zudem ist Prolog eine mächtige, aber recht kompakte Sprache. Eine abschließende Bewertung folgt am Ende dieses Abschnitts.

Ein zentraler Vorteil von Prologprogrammen ist die Richtungsunabhängigkeit von Prädikaten. Das klassische Beispiel ist die das Prädikat Append, die zwei Listen zu einer konkatenierten Liste transformieren kann. Gleichzeitig kann es in anderen Aufrufvarianten benutzt werden, z.B. zur Extraktion von Prä- und Suffixen und zur Generierung von Listen-Teilen.

Eine Liste ist entweder die leere Liste (geschrieben als [], auch Nil genannt) oder ein Element gefolgt von einer Liste (angedeutet durch [_|_], auch Cons genannt).

append([], X, X).
append([Head|Tail], X, [Head|Result]) :- append(Tail, X, Result).

/* Beispiele:
append([1,2], [3,4], L). -> L = [1,2,3,4].
append([1,2], Suf, [1,2,3,4]). -> Suf = [3,4].
append(Pre, [3,4], [1,2,3,4]). -> Pre = [1,2].
append(Pre, Suf, [1,2,3,4]). ->
  Pre = [], Suf = [1,2,3,4];
  Pre = [1], Suf = [2,3,4];
  Pre = [1,2], Suf = [3,4];
  Pre = [1,2,3], Suf = [4];
  Pre = [1,2,3,4], Suf = [].
*/

Auffällig ist die Kürze des Append-Prädikats. Nur Zwei Zeilen sind nötig, um die Eigenschaften von Append zu formulieren:
Die erste Zeile lässt sich so beschreiben: Die Konkatenation der leeren Liste mit einer anderen Liste ist die andere Liste. Diese Zeile stellt den Rekursionsabbruch dar.
Die zweite Zeile besagt: Um eine nicht-leere Liste aus Head und Tail mit einer anderen Liste zu konkatenieren, wird der Head in die Ergebnisliste übernommen und der Rest des Ergebnisses wird durch die Konkatenation des Tails und der anderen Liste geliefert. Hier geschieht die Konsumption, die für das Terminieren der Rekursion wichtig ist, auf der ersten Argumentstelle.

Ein anderes wichtiges Prädikat, das mehrere Aufgaben erfüllt, die mit der Enthaltenseinbeziehung zusammenhängen, ist das Member-Prädikat:

member(Head, [Head|_]).
member(Element, [_|Tail]) :- member(Element, Tail).

/* Beispiele:
member(E, [1,2,3,4]). -> E = 1; E = 2; E = 3; E = 4.
member(3, [1,2,3,4]). -> yes.
member(5, [1,2,3,4]). -> no.
member(5, L). -> L = [5|_]; L = [_,5|_]; L = [_,_,5|_]; ...
*/

Wieder lässt sich eine natürlichsprachliche Formulierung finden: Der Kopf der Liste ist Element der Liste, ebenso wie Elemente des Restes der Liste.

Mit dem Prädikat kann man durch eine Liste iterieren, Werte auf Enthalten-sein prüfen und es lassen sich (unendlich viele) Listen generieren, die ein bestimmtes Element enthalten. Die letzte Ausgabe zeigt außerdem eine weitere Besonderheit von Prolog: die Verwendung von freien Variablen in Datenstrukturen. Eine weitere Eigenschaft von Prädikaten wird deutlich: Die Klauseln, aus denen das Prädikat besteht, müssen einander nicht ausschließen.

Unifikation

Der Unifikations-Mechanismus versucht, zwei Werte gleich zu machen, indem Variablenbindungen hergestellt werden. Sind zwei Terme nicht unifizierbar, ist das Ergebnis false (was zum Abbruch des Prädikats führt), andernfalls werden die Bindungen hergestellt und das Ergebnis ist true (was zur weiteren Ausführung des Prädikats führt).

Der Mechanismus unterscheidet, welche zwei Werte miteinander unifiziert werden sollen. Es gibt in Prolog als Werte nur Atome (wie Symbole, Zahlen, Bool’sche Werte), Variablen und Strukturen.
Da Unifikation symmetrisch ist, gibt es nur die folgenden Fälle (gebundene Variablen entsprechen ihrem gebundenen Wert, daher gibt es hier nur freie Variablen):
FreieVariable = FreieVariable führt zur Koreferenz von zwei Variablen (wird im Folgenden eine der beiden gebunden, wird es die andere auch).
FreieVariable = konstante führt zur Bindung der Variablen an die Konstante.
FreieVariable = struktur(...) führt zur Bindung der Variablen an die Struktur.
konstante = konstante unifiziert, weil die Konstanten gleich ist.
struktur(...) = struktur(...) unifiziert, wenn die Stelligkeit der Strukturen übereinstimmt und alle Argumente rekursiv unifiziert werden können.

Einordnung von Prolog

Prolog wird oft für Wissensdatenbanken verwendet, denn Datenbankanfragen sind leicht zu schreiben, z.B. ist kunde(2, Name) die Abfrage des Namens des Kundens mit der Nummer 2. Voraussetzung ist das Wissen über die genaue Struktur der Datenbank; in dem Beispiel die Kenntnis, dass kunde eine zweistellige Relation ist, deren ersten Argumentstelle die Kundennummer und die zweite Stelle der Name ist. Eine Datenbank besteht aus Fakten:

kunde(1, john).
kunde(2, paul).
kunde(3, george).
kunde(4, ringo).

Die Ausgabe für die Beispielabfrage kunde(2, Name) ist Name = paul.

Der Bezug zur Definition Formulieren von Regeln und Zusammenhängen ist durch folgende Eigenschaften hergestellt:

  • Formulieren ist das Schreiben von Prädikaten.
  • Regeln sollen Fälle unterscheiden: Das passiert in Prolog mithilfe von Prädikaten, die Fälle klassifizieren. Die Unterscheidungen nimmt der Prolog-Programmierer durch geeignete Klausel-Köpfe vor (im Append-Beispiel durch Unterscheidung nach [] oder [Head|Tail]). Zudem können Fälle im Klausel-Körper mithilfe von beliebigen Prädikaten genauer unterschieden werden.
  • Zusammenhänge führen zum Berechnungsergebnis. Dies ist mit funktionalen Zusammenhänge der Form X is Y + Z möglich, aber vor allem durch Verwendung der mithilfe von Prädikaten definierten Relationen.

Mithilfe von Prolog kann das Problem auf hoher Abstraktionsebene beschrieben werden und das System übernimmt die Suche nach Lösungen. Prolog eignet sich zur Lösung von Logikrätseln, Beschreibung von Spielregeln, Datenbankabfragen, Listenverarbeitung, Suche in Hierarchien, Sprachverarbeitung und Anwendungen im Bereich der Künstlichen Intelligenz (KI). Eine weitere große Stärke ist Metaprogrammierung (Code-Generierung und -Auswertung) und die Definition eigener Operatoren, um eine eigene (domänen-spezifische) Sprache zu entwickeln.

Berechnung von arithmetischen Ausdrücken wird durch die Vorgabe, Prädikate zu verwenden, erschwert. Das Schreiben von funktionalen Ausdrücken wie N - 1 führt zur Erstellung der Struktur -(N, 1), welche mit dem is-Prädikat ausgerechnet werden kann. Die Quadrierungsfunktion x \mapsto x \cdot x ist beispielsweise in Prolog als richtungsabhängiges Prädikat zu schreiben: square(N, NmalN) :- NmalN is N * N..
Zustandsabhängige Programmierung ist durch spezielle Prädikate wie assert und retract (zur Veränderung der Wissensbasis) möglich.

Außen vor gelassen wurde in dieser Betrachtung die Negation und der Cut, welche beide in realen Prolog-Anwendungen häufig verwendet werden.

Prolog ist dynamisch typisiert, was insbesondere Listenverarbeitung leicht macht, wodurch sich aber einige Programmier-Fehler erst zur Laufzeit bemerkbar machen.

Prolog und funktionale Programmierung

Die Erben von Prolog sind unter anderem Curry und Mercury, zwei logikfunktionale Sprachen, die unter anderem schnellen C-Quelltext produzieren und dem Programmierer Features von Prolog und funktionalen Programmiersprachen wie Haskell (im Fall von Curry) bieten.

Aktuell sind funktional-objektorientierte Sprachen wie Scala und F# auf dem Weg, populär zu werden. Das lässt sich durch aussagekräftigeren und kürzeren Quelltext, aber auch durch Vorteile bei paralleler Programmierung erklären. Es ist abzuwarten, ob sich logikfunktionale Sprachen durchsetzen werden. An der Universität in Kiel wird beispielsweise Curry gelehrt, wobei funktionale und Logik-Programmierung mittels einer Programmiersprache unterrichtet werden kann [Curry, S. 334].

Das Konzept Pattern matching spielt in Miranda und anderen funktionalen Programmiersprachen eine wichtige Rolle. Pattern matching ist eine eingeschränkte Form der Unifikation, bei der nur die linke der beiden Seiten Variablen enthalten darf.

2.2 Miranda

In dem Buch Functional Programming with Miranda [FPWithMiranda] wird nicht nur die rein-funktionale Programmiersprache Miranda vorgestellt, es geht auch darum, verständlichen Quelltext zu schreiben, der an der Mathematik angelehnt ist. Dazu wird beispielsweise auf Funktionen und Rekursion zurückgegriffen.

Programme, die in funktionalen Programmiersprachen geschrieben sind, bestehen aus Funktionen, die Eingabe-Werte auf Ausgabe-Werte abbilden. Das Attribut rein-funktional fordert, dass alle Funktionen referenziell transparent sind.

Gleichungen bestehen aus dem Musterabgleich (Pattern matching) auf der linken Seite und der Berechnungsvorschrift auf der rechten Seite.

Dies stellt den Bezug zur Definition Formulieren von Regeln und Zusammenhängen her: Regeln werden durch Muster auf der linken Seite formuliert und die rechte Seite stellt den funktionalen Zusammenhang dar. Es können für eine Funktion mehrere Gleichungen geschrieben werden, um Fälle zu unterscheiden. Wie in anderen funktionalen Programmiersprachen werden anstelle von Schleifen-Konstrukten rekursive Funktionen verwendet.

Referenzielle Transparenz verhindert Seiteneffekte Eine Manifestation von Seiteneffekten ist das Verändern des Zustandes eines Objektes, welches unter einem Alias, d.h. mehr als einem Namen [SICP, S. 295] zugreifbar ist. und führt zur Gleichbehandlung von Gleichheit und Identität von Werten. Außerdem bringt sie noch den Vorteil der Wiederverwendung von Datenstrukturen. Nur wenn auf Seiteneffekte verzichtet wird, ist verzögerte Auswertung (laziness) sinnvoll, welche wiederum die Arbeit mit unendlichen Listen ermöglicht. Gleichzeitig werden änderbare Arrays als wichtigste imperative Datenstruktur verhindert [FPWithMiranda, S. 93]Stattdessen werden oft verschiedene Arten von Bäumen verwendet.. Eine gute Übersicht, wie mit dem Problem umgegangen wurde und welche Arten von funktionalen Arrays entwickelt wurden, gibt [FuncArrays, S. S. 2-3]. In neueren multiparadigmatischen Sprachen wie F# und Scala gibt es jedoch die Möglichkeit, auf imperative Arrays wie in C# oder Java zuzugreifen, weshalb nicht weiter auf funktionale Arrays eingegangen wird.

Miranda verfügt als rein-funktionale Programmiersprache nicht über Zuweisungen. Stattdessen gibt es Variablenbindungen, die einen Bezeichner an einen Wert binden. Dank Laziness wird der Wert erst dann berechnet, wenn er wirklich zur Ermittlung eines Berechnungsergebnisses benötigt wird.

Eine Besonderheit der Sprache Miranda ist, dass auf stukturierende Klammern wie etwa in if (Condition) { ThenBlock } else { ElseBlock } verzichtet wird. Stattdessen wird die sogenannte off-side rule verwendet, in der die Einrückungstiefe den Geltungsbereich von Variablen bestimmt, sodass gänzlich auf strukturierende Block-Klammern verzichtet werden kann.Die off-side rule wird ebenfalls in F# verwendet und bezieht sich dort unter anderem auf die Einrückungstiefe bei let-Bindungen. [FSharpSpec, vgl. S. 232ff.]

Eine zweite Besonderheit ist die Typinferenz, dank derer auf Typ-Annotation verzichtet werden kann, wodurch der Code von Typisierungs-Details befreit wird. Allein aus der Verwendung von Parametern kann deren Typ abgeleitet werden. Werden im Quellcode keine besonderen Operationen mit Werten durchgeführt, die auf den Typ schließen lassen, bleibt der Typ offen und funktioniert für alle konkreten Typen (generische Programmierung).

Diese Eigenschaften führen zu schönen Programmen und Programmbestandteilen, wie etwa die bekannten Funktionen Map, Filter, Fold, die viele Iterationsaufgaben elegant lösen. Dazu werden Listen rekursiv verarbeitet, indem eine Funktion auf den Kopf und Rest der Liste hat zugreift und diese zu einem Ergebnis transformiert.

||| Abbildung einer Liste mit Transformationsfunktion
||| Beispiel: map (+1) [1,2,3,4] -> [2,3,4,5]
map f [] = []
map f (head:tail) = (f head) : (map f tail)

||| Filterung einer Liste mit Prädikat
||| Beispiel: filter (>1) [1,2,3,4] -> [2,3,4]
filter pred [] = []
filter pred (head:tail)
= head : (filter pred tail), if pred(head)
= filter pred tail,          otherwise

||| Zusammenfalten einer Liste mit Startwert und 2-stelliger Funktion
||| Beispiel: fold 0 (+) [1,2,3,4] -> 10
fold seed f [] = seed
fold seed f (head:tail) = fold (f seed head) f tail

Die Funktionsweise von Map, Filter und Fold lässt sich wie in Abbildung # illustieren.

mapfilterfold
Vereinfachte Funktionsweise von Map, Filter und Fold [FPWithMiranda, nach S. 42ff.].

Map, Filter und Fold sind sogenannte Funktionen höherer Ordnung, weil sie als Parameter Funktionen aufnehmen (hier f und pred).
Pattern matching wird ähnlich wie in den Prolog-Prädikaten aus Abschnitt Prolog wieder benutzt, um den Rekursionsabbruch darzustellen.

Mit partieller Anwendung von Funktionen (currying) lassen sich aus vorhandenen Funktionen neue Funktionen erstellen, die weniger Argumente benötigen. In dem Beispiel fold 0 (+) [1,2,3,4] wird deutlich, dass man die Summe einer Liste bilden möchte. Mathematiker kennen dafür die (n-stellige) Summe, die mit \sum dargestellt wird. Programmierer sollten auch Zugriff auf dieses Konstrukt haben und könnten sich eine entsprechende Funktion definieren. Für das (n-stellige) Produkt gibt es \prod, welches sich auch definieren ließe. Die Integration von erweiterten Unicode-Zeichen in Programmiersprachen ist noch nicht gelungen, was an Schwierigkeiten bei der Eingabe mit der Tastatur und unflexiblen Parsern liegt.Eine Betrachtung des Themas Unicode in Programmiersprachen findet in [FunktProg, S. 4-5] statt. Daher werden sprechende Namen statt mathematischer Symbole verwendet:

sum = fold 0 (+)    ||| n-stellige Summenfunktion
prod = fold 1 (*)   ||| n-stellige Produktfunktion

Obwohl fold eine Funktion ist, die zur Berechnung drei Argumente benötigt, lassen sich auch weniger Argumente übergeben, sodass eine Funktion konstruiert wird, die nur noch auf das letzte Argument wartet, um das Ergebnis zu berechnen. Zwecks Dokumentation verzichtet man in Funktionsdefinitionen gelegentlich auf diese Eigenschaft und schreibt sum numbers = fold 0 (+) numbers.

Abgesehen von Typen, die später genauer betrachtet werden, sind dies die Kernideen vieler funktionaler Programmiersprachen. Eine kurze Auflistung von Eigenschaften funktionaler Programmierung, mit Miranda als Beispiel für eine rein funktionale Programmiersprache, bietet [FPWithMiranda, S. 8-9]:

  • Algorithmen können funktional mit Klarheit und Kürze formuliert werden.
  • Kürzere Programme sind leichter zu schreiben, zu testen, anzupassen und zu warten.
  • Funktionale Programmiersprachen sind mathematisch formalisierbar und lassen sich durch referenzielle Transparenz leichter parallelisieren.
  • Die Nachteile gegenüber prozeduralen Programmen waren jedoch geringere Verfügbarkeit (der Laufzeitumgebung für Miranda beispielsweise), fehlende Interoperabilität zur Systemprogrammierung (Betriebssystem-, Datenbankbibliotheken) und geringere Performanz.

Die eben genannten Nachteile wurden durch intensive Forschung reduziert und neue funktionale Programmiersprachen lösen diese Anforderungen zufriedenstellend. Die Integration mit anderen Programmiersprachen und Interoperabilität von Programmbibliotheken ist auch durch gemeinsame Frameworks und Laufzeitumgebungen gelungen.

3 Deklarativer Stil um 2000

Bearbeitet: Heute war zu allgemein, durch eine andere Bezeichnung oder durch Jahr ersetzen -> Durch eine Jahreszeitspanne ersetzt.

Im Zusammenhang mit paralleler Programmierung und Daten-basierten Programmen sind funktionale Programmiersprachen für heutige Programmierung wichtig geworden. Da Objektorientierung oft auf einem imperativen Kern aufbaut, ist das Paradigma für parallele Ausführung weniger geeignet, wohingegen reine funktionale Programmierung weiterhilft [RealWorldFP, S. 10-11].
Logikprogrammierung ist im Bereich der KI wichtig, für typische Anwendungs-Programmierung aber nicht ausgelegt (gemeint sind z.B. grafische Benutzerschnittstellen, Webentwicklung oder Computer-Spiele).

Symbol- und Zahlenmanipulation ist einer der Kernbereiche der funktionalen Programmierung und die Integration mit objektorientierten popuären Frameworks wie .NET und dem Java-Framework erlaubt den Umstieg von objektorientierten Programmiersprachen zu funktionalen Sprachen.

Es gibt viele funktionale Programmiersprachen, die ihre Vorteile und Eigenheiten haben, vor allem was Effizienz und Interoperabilität anbelangt. Eine neue bzw. neu entdeckte Entwicklung sind multiparadigmatische Programmiersprachen. Mit ihnen lassen sich Paradigmen wie Objektorientierung und funktionale Programmierung vereinen. Bekannte Vertreter sind Scala für die JVM als Programmiersprache, die gut mit Java-Bibliotheken zusammenarbeitet, und F# für das .NET-Framework.
Beide sind statisch typisierte funktionale Programmiersprachen, verfolgen aber im Gegensatz zu Miranda strikte Auswertung und übernehmen das objektorientierte Typsystem aus dem zugrundeliegenden Framework (Java oder .NET).

Scala ist als besseres Java entworfen worden und löst viele typische Probleme aus Java. Die vielen funktionalen Aspekte von Scala lassen sich bei der Programmierung für die Java-Plattform gewinnbringend einsetzen. Der Name Scala steht für scalable Language und bezieht sich auf die (im Vergleich zu Java) flexible Syntax und Erweiterbarkeit der Programmiersprache.

F# wurde ursprünglich als OCaml-Variante für .NET entwickelt, bietet nun aber von ML unabhängige Konzepte, welche die Programmierung durch geeignete Modularisierung erleichtern. Für C#-Programmierer ist F# durch seine Kürze und Aussagekraft eine gute Alternative. Dem Programmierer wird nicht nur oftmals das lästige Schreiben von Typannotationen abgenommen, die Programme sind durch ihren funktionalen Charakter meist kürzer, verständlicher und näher an der Intention des Autors als vergleichbare C#-Programme. Da F# zudem auch Werkzeugunterstützung bietet, ist es eine gute Wahl für .NET-Programmierer. An dieser Stelle soll keine Beschreibung der Werkzeugunterstützung stattfinden, es soll nur erwähnt sein, dass der Editor Autovervollständigung und Kontext-Hilfe besitzt sowie über einen interaktiven Prompt verfügt. Der interaktive Prompt nennt sich F# interactive und wird im Rahmen von Quellcode-Beispielen in dieser Arbeit benutzt. Die Notation ist wie folgt zu lesen:

> Ausdruck ;;
val it: Typ = Wert

Hinter dem Zeichen > zur Eingabeaufforderung wird ein Ausdruck eingegeben; die Eingabe wird mit der Endesequenz ;; abgeschlossen. Die Ausgabe enthält den Typ und den Wert des ausgewerteten Ausdrucks.

Modularisierung und Aussagekraft sind zwei treibende Faktoren bei der Verwendung einer Programmiersprache. F# bietet in dieser Hinsicht neue Techniken, die richtig verwendet zur deklarativen Programmierung führen. Deshalb wird im Folgenden F# als Beispiel für moderne deklarative Programmierung benutzt und analysiert. Dazu wird zunächst ein Muster vorgestellt, mit dem die wichtigen Konzepte besprochen und abgewägt werden können.

3.1 Analyse von deklarativen Sprachelementen

Programmiersprachen werben mit Features: In der einen Programmiersprachen wird eine typische Aufgabe mit weniger Schreibaufwand gelöst, als in einer anderen. Design von Programmiersprachen ist eine hohe Kunst, jedoch keine elitäre Angelegenheit mehr. Tools und Tutorials können dem Laien die Konstruktion einer Programmiersprachen erleichtern. Viele Programmiersprachen sind Verschmelzungen von anderen ähnlichen Programmiersprachen unter Hinzunahme von Eigenschaften und Konstrukten nach Geschmack des Konstrukteurs.

Gerade deshalb ist ein roter Faden, der im Programmiersprache-Design zu finden sein muss, Pflicht. Die Orientierung an einem Paradigma wie dem funktionalen oder dem objektorientierten kann solch ein Faden sein; die Angst jedoch, einer anderen Sprache in etwas nachzustehen, verführt jedoch wieder zur Hinzunahme von beliebigen Features und zum Verlust dieses Fadens.In dem Zusammenhang könnten multiparadigmatische Programmiersprachen als unstrukturiert erscheinen; bei genauerer Betrachtung werden jedoch Paradigmen integriert, um einen eleganten Problemlösungsweg auch auf konzeptueller Ebene zu ermöglichen.

Ich schlage eine Struktur vor, mit der Programmiersprachenfeatures im Allgemeinen und deklarative Sprachelemente im Speziellen analysiert werden können. In dieser Arbeit liegt das Ziel der Analyse darin, deklarative Sprachelemente zu vergleichen. Das Schema beleuchtet kurz folgende Aspekte eines Sprachelements oder einer Technik der Programmiersprache:

Technik: Aussagekräftige Bezeichnung für das Konstrukt
Zweck: Kurze Beschreibung des Nutzens
Problem: Probleme, die damit gelöst werden können
Lösung: Verwendung dieses Konstruktes
Performanz: Illustration der Umsetzung / Ausführung des Konstruktes
Alternative: Verwandte Techniken, die ähnliche Probleme lösen können oder alternativer Ansatz der Lösung

Anhand von Beispielen werden danach Vor- und Nachteile bei der Verwendung illustriert. Aus den Beispielen muss außerdem die Syntax des Sprachelementes erkennbar sein.

3.2.1 Definition und Verwendung von Typen


Unter einem Datentyp (im folgenden nur Typ) versteht man eine Menge von zulässigen Werten als Operanden und Ergebnisse sowie von darauf anwendbaren Operationen in einer Programmiersprache [InformatikLexikon, S. 215].

Typ-Definitionen in F# sind dank der aus ML geborgten Notation aussagekräftiger als in C#. Insbesondere algebraische Datentypen sind bei der Programmierung hilfreich und wären in C# und anderen objektorientierten Sprachen aufwendig zu formulieren.

In F# gibt es folgende Arten von TypenEnum-, Delegat-, Exception- und Maßeinheit-Typen werden hier nicht aufgeführt, weil es sich um besondere Structs oder Klassen bzw. Maßeinheiten-Metadaten handelt. Genaueres über diese Typen findet sich in der F#-Spezifikation [FSharpSpec, vgl. S. 115-116].:

Funktionstyp

In einer funktionalen Programmiersprache ist das wichtigste Element die Funktion. Eine Funktion bildet Eingabe-Werte auf Ausgabe-Werte ab.

Funktionen sind Werte von Funktionstypen. Funktionstypen haben die Form Eingabetyp -> Ausgabetyp, wobei Eingabe- und Ausgabetyp beliebige Typen sind. Der Typ der Quadrierungsfunktion (x \mapsto x^2) ist leicht verständlich: int -> int. Im Fall von partieller Applikation sehen Funktionstypen etwas interessanter aus. Arithmetische Operationen (etwa +, -, *, /) und Vergleiche (wie >, <=) erwarten zwei Argumente, um ausgeführt zu werden. Die Applikation des Operators auf das erste Argument liefert eine Funktion, die nur noch das zweite Argument erwartet. Das wird im Fall der Addition für Ganzzahlen so dargestellt: int -> (int -> int). Der Eingabetyp ist int, d.h. der erste Eingabewert ist eine ganze Zahl und der Ausgabetyp ist eine Funktion vom Typ int -> int. Dies stellt den Typen der Funktion dar, die das zweite Argument erwartet. Die Klammerung von Funktionstypen ist rechtsassoziativ, deshalb wird statt int -> (int -> int) gerne int -> int -> int geschrieben.

Ein Sonderfall von Funktionstypen sind die Typen von Funktionen höherer Ordnung. Map funktioniert auf Listen eines beliebigen aber festen Typs (nennen wir den Elementtyp 'a). Der Funktionstyp von Map lautet ('a -> 'b) -> 'a list -> 'b list. Es wird als erstes Argument eine Funktion erwartet, die einen Wert vom Typ 'a auf einen Wert vom Typ 'b abbildet (man sagt kürzer ein 'a auf ein 'b abbildet. Die Klammerung um Funktionstypen bei Parametern ist wichtig.) Als zweites Argument wird eine Liste von 'as erwartet; wird die Funktion darauf angewendet, wird eine Liste von 'bs geliefert, deren Elemente aus den Elementen der Eingabeliste und der Abbildungsfunktion entstehen.

Die Definition von Funktionstypen geschieht in F# implizit durch das Definieren von Funktionen.

Algebraischer Datentyp


Algebraische Datentypen (kurz ADT, auch union types) sind Typen, die eine abgeschlossene Anzahl an Varianten haben. Sind den Varianten keine zusätzlichen Daten zugeordnet, sind dies Werte des Typs; andernfalls nennt man die instanziierten Varianten Werte des Typs. Varianten sind oft Daten von Produkttypen zugeordnet. Produkttypen sind die Typen von n-Tupeln (Typen die durch Bildung des kartesischen Produktes über n Typen entstehen).

Bearbeitet: Minimale algebraische Definition und Varianten vs. Werte

Beispiele sind Bool’sche Werte (Typ bool mit den zwei Varianten bzw. Werten true und false) oder das Nulltupel (Typ unit mit dem Wert ()), aber auch Datenbehälter wie etwa der Typ aus einer Variante Punkt (mit allen Werten der Form Punkt(a, b) mit konkreten Ganzzahlen a und b).

Wenn man von mehr als einer Variante spricht, nennt man diese auch Summentypen und verwendet sie um inhaltlich verwandte Elemente, die aber strukturell unterschiedlich aufgebaut sein können, zusammenzufassen [FunktProg, S. 17].

Wichtig sind vor allem generische algebraische Datentypen (kurz GADT), die beliebige aber festen Elementtypen enthalten können, sodass strukturierte Daten konstruiert und verarbeitet werden können. Das klassische Beispiel ist eine Liste eines bestimmten Elementtyps. Eine Liste von ‚a (Liste von Elementtyp 'a) lässt sich so definieren:

  • Die leere Liste ist eine Liste von ‚a.
  • Eine Element vom Typ 'a gefolgt von einer Liste von 'a ist eine Liste von 'a.
  • Nur diese beiden Varianten erzeugen Listen von 'a.

Den beiden Varianten müssen Namen gegeben werden, um mit ihnen zu arbeiten: Die leere Liste wird Nil und das Paar von Element und Liste wird Cons genannt. [1,2,3,4] ist eine Liste von Ganzzahlen (int list) und ist aus den beiden Varianten konstruiert: Cons(1, Cons(2, Cons(3, Cons(4, Nil)))). Eine wichtige Infix-Schreibweise ist 1::2::3::4::[], wobei [] für Nil und a :: b für Cons(a, b) steht und rechtsassoziativ ist (a :: b :: c = a :: (b :: c)). Die Liste stellt eine der wichtigsten Datenstrukturen in der funktionalen Programmierung dar. Sie ist ein Beispiel für rekursiv definierte Typen; ein anderes Beispiel ist der Typ von Binärbäumen. Der Binärbaum Node(2, Node(1, Node(0, Empty, Empty), Empty), Node(4, Node(3, Empty, Empty), Node(5, Empty, Empty))) lässt sich wie in Abbildung # visualisieren.


baum
Ein Binärbaum

Andere wichtige generische algebraische Datentypen sind die Typen von Tupeln ('a * 'b), Tripeln ('a * 'b * 'c), Quadrupeln ('a * 'b * 'c * 'd) usw., wobei die Typen der Komponenten beliebig aber fest sind. Algebraische Datentypen mit einer Variante sind nützlich, aber eher ungebräuchlich, da auf Tupel oder Datensätze für diesen Zweck zurückgegriffen werden kann. Außerdem wird im Falle von partiell definierten Funktionen Gebrauch vom generischen Option-Typ gemacht, der aus den Varianten None oder Some(x) mit Werten x vom Typ 'a besteht. Z.B. kann die ganzzahlige Division so dargestellt werden, dass für Werte a und b das Ergebnis None im Fall von b = 0 und Some(a/b) sonst ist.

Algebraische Datentypen werden in F# folgendermaßen definiert:

type Unit = Unit // eingebaut als Typ unit
type Bool = True | False // eingebaut als primitiver Typ bool
type Punkt = Punkt of int * int
type List<'a> = Nil | Cons of 'a * List<'a>
// eingebaut als Typ list<'a>
type Binary<'a> = Empty | Node of 'a * Binary<'a> * Binary<'a>
type Option<'a> = None | Some of 'a // eingebaut als Typ option<'a>
type Tupel<'a, 'b> = Tupel of 'a * 'b // eingebaut als Typ 'a * 'b
type Tripel<'a, 'b, 'c> = Tripel of 'a * 'b * 'c
// eingebaut als Typ 'a * 'b * 'c

Wie eingangs erwähnt und wie aus den Beispielen deutlich wird, ist die Notation äußerst kompakt. Vergleichbare Definitionen in objektorientierten Sprachen sind wesentlich länger, weil dem Programmierer auferlegt ist, Klassen, Unterklassen, Konstruktoren und Felder zu schreiben. Außerdem sind korrekte Equals– und GetHashCode-Methoden zu implementieren. Gerade bei algebraischen Datentypen muss sichergestellt werden, dass keine weiteren Varianten durch Unterklassenbildung hinzugefügt werden können.

Der deklarative Stil der obigen Defintionen ist bemerkenswert. Nicht nur bei der Definition, sondern auch bei der Verwendung haben algebraische Datentypen Vorteile gegenüber Klassen, siehe dazu den Eintrag Algebraischer Datentyp im Abschnitt Pattern Matching.

Datensatz


Datensätze (record types) sind Typen, die als Datenbehälter fungieren. Die Verwendung von Datensätzen ist Tupeln vorzuziehen, wenn komplexere Datenstrukturen als Argument übergeben oder von Funktionen geliefert werden. Tupeln gegenüber haben die Bestandteile von Datensätzen keine feste Ordnung, jedoch einen Namen.

Eine Person sollte in einem Programm nicht als Tupel vom Typ (string * string) dargestellt werden, wobei die Komponenten Vorname und Nachname darstellen sollen. Stattdessen kann ein Datensatz definiert werden:

type Person = { Vorname: string; Nachname: string }
// Beispiel für ein Datensatzobjekt:
let MsCarter = { Vorname = "Samantha"; Nachname = "Carter" }

Die Definition solcher Datenbehälter ist auf das Nötigste reduziert; insbesondere muss man keine Konstruktoren oder Equals-Methoden implementieren, was fehlerträchtig sein kann und in vielen objektorientierten Sprachen für jeden Typen von Hand getan werden muss; eine Betrachtung dazu findet sich im Abschnitt Imperativ-objektorientierte Typen. Zwei zusätzliche Eigenschaften sind bei Datensätzen zu erwähnen:

  1. Muster zur Extraktion von Daten stehen zur Verfügung, siehe dazu den Eintrag Datensatz im Abschnitt Pattern Matching.
  2. Geringfügige Änderungen von Datensätzen können mit dem with-Operator durchgeführt werden, wobei eine neuer Datensatz erstellt wird, welche dem Vorlage-Datensatz-Objekt bis auf die angegeben Felder gleicht:

    let MrsMcKay = { MsCarter with Nachname = "Mc Kay" }
    

Klasse und Interface


Eine Klasse ist der Typ eines Objektes. Objekte haben einen internen Zustand, der nur durch Operationen verändert oder sondiert werden darf. Klassen können voneinander abgeleitet sein, wodurch die Unterklasse Eigenschaften (Zustand und Verhalten) von der Oberklasse übernimmt. Der Zustand kann in Unterklassen erweitert und Verhalten abgeändert werden.
Die Menge der Operationen einer Klasse ist ihre Schnittstelle.


Interfaces sind lediglich eine Menge von Operationen ohne Implementierung. Klassen können Interfaces implementieren, wodurch Objekte dieser Klassen unter der Sicht des entsprechenden Interfaces benutzt werden können.

Bearbeitet: Operation->Methode = Dynamisches Binden; Austauschen = Subtyp-Polymorphie

Das Aufrufen von Operationen an Objekten und das Auswählen der klassenspezifischen Methode, um die Operation auszuführen, nennt sich dynamisches Binden. Die Idee ist, dass der Aufruf einer Operation nicht fest an eine Methode gebunden ist, sondern flexibel zur Laufzeit ausgetauscht werden kann. Das Austauschen geschieht über Subtyp-Polymorphie (Subtypen sind die oben erwähnten Unterklassen; Polymorphie steht für Vielgestaltigkeit), d.h. Klassenvererbung und Überschreiben von Methoden. Diese Flexibilität ist Grundlage vieler Entwurfsmuster [Entwurfsmuster, vgl. S. 16] und wird als Technik im Abschnitt Imperativ-objektorientierte Fallunterscheidungen erläutert.

Struct


Structs stellen Typen von Werten dar, die nicht wie Objekte auf dem Heap sondern auf dem Aufrufstack gespeichert werden. Dieser Aspekt hat und Vor- und Nachteile, die erst betrachtet werden müssen, wenn Performanz eine Rolle spielt. Diese Betrachtung wird im Abschnitt Imperativ objektorientierte Typen vorgenommen.

3.2.2 Pattern matching

Technik: Pattern matching
Zweck: Fallunterscheidung und Wertextraktion
Problem: Typprüfungen gehen mit Typecasts und Datenextraktion einher, sodass die zu unterscheidenden Fälle aufwendig zu programmieren sind. Selektor-Funktionen (OO: Getter) werden exzessiv genutzt, um Daten zu extrahieren.
Lösung: Pattern matching auf Berechnungsergebnisse und Parameter anwenden. Konstrukte: match Ausdruck with Fälle oder function Fälle
Performanz: Die Fälle werden in if-else-Ketten umgewandelt, switch wird im Fall von primitiven Datentypen und algebraischen Datentypen verwendet.
Alternative: if-else-Ketten, explizite Typprüfungen und Datenextraktion, switch, Try-Methoden, Subtyp-Polymorphie, Visitor-Pattern

Bereits in Miranda war Pattern matching eine Technik, um Fälle zu unterscheiden und gleichzeitig Werte aus strukturierten Daten zu extrahieren. Explizit zu schreibende Typprädikate und Selektoren wie etwa in Scheme im Sinne von [SICP. vgl. S. 120] werden damit unnötig, gleichzeitig geht aber auch die in dort motivierte Repräsentationsflexibilität verloren. Mehr zu diesem Punkt findet sich in der Evaluation der Fallunterscheidungen.

Um Pattern matching zu verstehen, müssen die verschiedenen Muster (Patterns) analysiert werden, vom einfachsten zum komplexesten:

Variable Wenn auch nicht sofort als Pattern ersichtlich, ist eine Variable ein Muster, das immer funktioniert und eine Variable bindet. Ein Spezialfall der Variable ist der Unterstrich, mit dem ausgedrückt wird, dass die Variable nicht gebunden werden soll.
Literal Literale sind Werte primitiver Datentypen, z.B. true, 42, 0.1, "string", 'x'. Sie passen genau auf diese Werte.
N-Tupel Muster der Form (a,b), (a,b,c) usw. passen auf Werte vom entsprechenden Tupel-Typ. Wichtig ist hier, dass a, b und c wiederum Muster sind (in diesem Fall Variablen).
Liste [] passt genau auf die leere Liste. a::b passt auf ein Cons-Paar (a und b sind wieder Muster). Listen mit expliziter Länge wie etwa [a;b;c] sind nur eine alternative Schreibweise für a::b::c::[].
Array Da Arrays immer eine feste Länge haben, wird die Länge im Muster implizit angegeben: Beispielsweise passt [||] auf das leere Array und [|a;b;c|] passt genau auf ein Array der Länge 3.
Algebraischer Datentyp Die Varianten eines algebraischen Datentyps können als Muster verwendet werden. Dazu wird der Variantenname mit den zugehörigen Daten notiert. Für den Typ, der mit type Punkt = Punkt of int * int definiert wird, wäre ein Muster, das auf einen Wert vom Typ Punkt passt Punkt(x,y). Auch Punkt tupel ist möglich, da der Inhalt eines Punktes ein Tupel ist.
Datensatz Ein Datensatz-Muster kann Felder eines Datensatz-Objektes extrahieren. Für den Typ, der mit
type Person = { Name: string; Geburtstag: DateTime }
definiert wird, stellt z.B. { Name = x } ein Muster dar, der den Wert des Feldes Name an die Variable x bindet. Anstelle von x kann wieder ein Muster verwendet werden; eine beliebige Anzahl an Feldern (mindestens jedoch eines) kann so extrahiert werden.
Konjunktion (&-Muster) Zwei Muster können mit & verknüpft werden, um ein neues Muster zu bilden, das passt, wenn beide Bestandteile passen. Ein Beispiel findet sich bei Active Patterns.
Disjunktion (|-Muster) Zwei Muster können mit | verknüpft werden, um ein neues Muster zu bilden, das passt, wenn mindestens ein Bestandteil passt. (Trifft das erste Muster zu, passt die Disjunktion; ansonsten wird das zweite Muster abgeglichen.) Z.B. ist (1|2|3) ein Muster, das auf eine Zahl passt, die 1, 2 oder 3 ist. Stellt eines der Muster Bindungen her, müssen alle Bestandteile diese Bindungen herstellen, sodass nach Erfolg des Musters auf dieselben Variablen zugegriffen werden kann.
Muster mit Bindung Einem Muster kann eine Bindung hinzugefügt werden, sodass der Wert, auf den das Muster passt, an eine Variable gebunden wird. Die Syntax ist Muster as Bezeichner.
Typtest Das Typtest-Muster passt auf einen Wert, wenn der Laufzeittyp des Wertes gleich oder ein Subtyp vom angegebenen Typ ist. Die Syntax ist :? Typ . Insbesondere in Verbindung mit einer Bindung (as) kann ein Typtests mit einem Typecast kombiniert werden. Ein gutes Beispiel ist die Equals(Object)-Methode:

type Pos(x: int, y: int) =
  member this.X = x
  member this.Y = y
  override this.GetHashCode() = this.X ^^^ this.Y // X xor Y
  override this.Equals(other: obj) =
    match other with
    | :? Pos as other ->
      this.X = other.X && this.Y = other.Y
    | _ -> false
Muster mit Guard Einem Muster kann ein Guard hinzugefügt werden, d.h. ein Bool’scher Ausdruck, der ausgewertet wird, wenn das Muster passt, und true sein muss, damit das Muster mit Guard passt. Die Syntax ist Muster when Ausdruck. Ein Muster mit Guard ist kein kompositionierbares Muster.
Active Patterns Active Patterns werden im gleichnamigen Abschnitt erklärt, wobei sie sogar parametrisiert sein können und zusätzliche Bindungen herstellen können.

Die vorgestellten Patterns werden üblicherweise in Konstrukten wie match Ausdruck with Fälle verwendet, wobei Fälle eine Auflistung von Fällen der Form Muster -> Behandlung ist. Da folgende gedankliche Äquivalenzen geltenDiese Äquivalenzen gelten z.B. nicht, wenn in Körper auf in der Funktion definierte mutable-Variablen zugegriffen wird (bei Klassen-Feldern ist dies wiederum erlaubt), weil für fun/function gewisse Eigenschaften von Closures eingehalten werden. Details dazu finden sich in [FSharp, vgl S. 56]., können Muster an vielen Stellen im Quelltext auftauchen:

let Muster = Ausdruck in Körper
\approx match Ausdruck with Muster -> Körper

fun (Muster) Parameter -> Körper
\approx fun x Parameter -> match x with Muster -> Körper

function Muster -> Körper
\approx fun x -> match x with Muster -> Körper

Dies stellt die beiden wichtigsten Anwendungsgebiete außerhalb von match-with dar: lokale Variablen und Parameter. An dieser Stelle sind Muster nur als Alternative für Typ-/Datenprüfung und Datenextraktion zu sehen, erst im nächsten Abschnitt Active Patterns wird die damit verbundene Modularität deutlich.

Muster sind deklarativ, weil deutlich formuliert wird, welchen Fall dieses Muster abdeckt und Zugriff auf Werte gegeben wird, ohne diese explizit extrahieren zu müssen. Der Gegensatz dazu ist z.B. explizite Typprüfung und Wert-Extraktion. Diese und andere Herangehensweisen werden im Teil Imperativ-objektorientierte Fallunterscheidungen untersucht.

Muster wurden im Prolog-Abschnitt schon für ihre kompakte Darstellung von Fallunterscheidungen gezeigt; ein wichtiger Unterschied ist jedoch, dass in F# (anders als in Miranda) Koreferenz in Mustern nicht erlaubt ist. Von in Muster vorkommenden Variablen mit gleichen Namen wird in Miranda gefordert, dass sie den gleichen Wert besitzen. In F# muss dies explizit geschrieben werden. Das Member-Beispiel aus Prolog ist in Miranda dank Koreferenz ähnlich aussagekräftig:

member x [] = false
member x (x:_) = true
member x (_:tail) = member x tail

In F# muss die Gleichheit explizit (z.B. mit einem Guard) geschrieben werden. Außerdem ist member als Schlüsselwort zur Definition von Methoden reserviert, weshalb hier der Name isMember benutzt wird:

let rec isMember x = function
| [] -> false
| head :: tail when x = head -> true
| _ :: tail -> isMember x tail

Die gezeigte rekursiven Definition lässt sich durch Funktionen höherer Ordnung in F# kürzer ausdrücken:
let isMember x = List.exists((=) x)
Hier geschieht die Iteration der Liste nicht explizit durch Rekursion, sondern es wird Folgendes ausgedrückt: Ein Wert x ist enthalten, wenn es ein Element gibt, das gleich x ist. Die Funktion List.exists führt die Iteration durch.

Pattern matching kann wie viele andere Techniken auch falsch verwendet werden. Sofern nur die Iteration einer Liste oder eine ähnlich einfache Aufgabe durchgeführt werden soll, sollte auf Funktionen höherer Ordnung zurückgegriffen werden. Wenn mit Zahlenbereichen und Relationen wie < gearbeitet wird, sollte if verwendet werden. In Verbindung mit Option-Werten werden ggf. längere Pattern-matching-Ketten, wobei eine Computation Expression wie der Option-Workflow verwendet werden sollte. Der Option-Typ definiert auch Funktionen höherer Ordnung, die zur Verarbeitung von Option-Werten benutzt werden können, wobei dies nur selten sinnvoll ist.

Andersherum arbeiten Pattern matching und Funktionen höherer Ordnung sehr gut zusammen, insbesondere beim Option-Typ. Seq.tryFind predicate sequence hat den Typ ('a -> bool) -> 'a seq -> 'a option und gibt das erste Element der Sequenz zurück, die das Prädikat erfüllt (als Some(element)); erfüllt kein Element das Prädikat, wird None zurückgegeben. Eine sinnvolle Verwendung ist z.B. das Anwenden der Funktion und sofortige Abgleichen mit den Option-Varianten:

> let gibGeradeZahlAus zahlen =
    match Seq.tryFind(fun x -> x % 2 = 0) zahlen with
    | Some(geradeZahl) ->
      printfn "%d ist die erste gerade Zahl" geradeZahl
    | None -> printfn "Keine Zahl war gerade";;
val gibGeradeZahlAus : seq<int> -> unit

> gibGeradeZahlAus [1; 2; 3];;
2 ist die erste gerade Zahl

3.2.3 Active Patterns

Technik: Active Patterns
Zweck: Funktionale Erweiterung von Pattern Matching
Problem: Nur primitive und algebraische Datentypen können in Pattern Matching verwendet werden, aber oft wird mit objektorientierten Klassen gearbeitet. Wiederholende Aufgaben wie Typprüfung und Wertextraktion von Objekten können in Funktionen gekapselt werden, die häufige Nutzung von Hilfsfunktionen verschleiert aber die Intention. Vorhandene Patterns sind nicht aussagekräftig oder tauchen als Duplikate auf.
Lösung: Active Patterns erweitern die Möglichkeit von Pattern Matching, indem Funktionen vor oder während des Matchings auf den Ausdruck angewendet wird. Konstrukte: (|X|), (|X|_|), (|X|Y|)
Performanz: Hängt von Pattern Matching und benutzten Funktionen ab.
Alternative: Explizite Funktionsaufrufe und explizite Definition von algebraischen Datentypen für das Ergebnis der Funktionen.

Um Active Patterns zu verstehen, ist es sinnvoll, kleine Beispiele dafür in expliziter Form zu sehen und diese mit dem entsprechenden Active Pattern zu vergleichen. Der einfachste Anwendungsfall ist der Klassifizierer.

Klassifizierer

type Vorzeichen = Negativ | Null | Positiv
let vorzeichen x =
  if x < 0 then Negativ else if x = 0 then Null else Positiv

let expliziteVerwendungVonFunktionen =
  match (vorzeichen -23, vorzeichen 0, vorzeichen 42) with
  | (Negativ, Null, Positiv) -> printfn "Test bestanden."
  | _ -> failwith "Test nicht bestanden."

Hier wird zunächst ein algebraischer Datentyp definiert, der das Ergebnis der Klassifikation bestimmt. Dann wird eine Funktion geschrieben, die eine ganze Zahl nach ihrem Vorzeichen klassifiziert. In einem kleinen Beispiel wird dies getestet.

Im folgenden wird eine kürzere Variante gezeigt, die Active Patterns benutzt und dasselbe leistet. Auffällig ist dabei der Name der zuvor vorzeichen genannten Funktion und das Wegfallen der Typdefinition und der Funktionsaufrufe. Active Patterns sind lediglich Funktionen, d.h. (|Negativ|Null|Positiv|) ist eine Funktion mit einem speziellen Namen, die in Pattern Matching automatisch verwendet wird.

let (|Negativ|Null|Positiv|) x =
  if x < 0 then Negativ else if x = 0 then Null else Positiv

let impliziteForm =
  match (-23, 0, 42) with
  | (Negativ, Null, Positiv) -> printfn "Test bestanden."
  | _ -> failwith "Test nicht bestanden."

An dieser Stelle wird deutlich: Das Muster (Negativ, Null, Positiv) passt auf alle Tripel-Werte, deren erste Komponente eine negative Ganzzahl ist, deren zweite 0 und deren dritte eine positive Ganzzahl ist. Auch wenn dieses Spielbeispiel nicht besonders hilfreich erscheint, ließen sich damit schon folgende Refactorings durchführen: Muster mit guard der Form ...x... when x > 0 lassen sich durch Benutzung von (Positiv as x) vereinfachen. Und wo auch immer Funktionen mit Ganzzahlen arbeiten, die positiv sein müssen, ließe sich ein anfänglicher Test der Form
let f(x) = if not(x > 0) then invalidArg "x" "x > 0 muss gelten" else Körper
auf der Parameter-Stelle von x in der Form
let f(Positiv as x) = Körper
einbauen (die Fehlernachricht ist dann allerdings nicht aussagekräftig).

Der erste Vorschlag führt zur zweiten Form von Active Patterns: Partial Active Patterns, die in Kürze gezeigt werden.

Der zweite genannte Anwendungsfall, die Validierung eines Argumentes, führt zu einem Active Pattern, welches eine Exception werfen kann. Diese Art von Active Pattern nenne ich Validierer. In der folgenden Variante handelt es sich um ein Parameterised Active Pattern, da name ein Parameter ist, der wie beispielsweise "n" in (NichtNegativ "n" n) übergeben wird.

Validierer und Parameterised Active Pattern

let (|NichtNegativ|) name x =
  if x >= 0 then x
  else invalidArg name (name + " darf nicht negativ sein.")

let kleinerGauß(NichtNegativ "n" n) = n * (n+1) / 2

Eine sehr einfache Verwendung der Form (|X|) ist eine Abbildung, die immer gelingt und einen Wert liefert:

Konvertierter

let (|Betrag|) x = abs x
let (|AlsString|) x = string x
let (|AlsDouble|)(x: obj) = System.Convert.ToDouble(x)

Auffällig ist vielleicht die Verwendung von Funktionen, die lediglich angewendet werden. Ein Muster der Form let (|Apply|) f x = f x könnte diese beiden gezeigten ersetzen (als Muster (Betrag betrag) oder (Apply abs derBetrag) und (AlsString text) oder (Apply string derText)). Dieses Active Pattern ist im Allgemeinen nicht sinnvoll, weil Active Patterns die Lesbarkeit verbessern sollen, indem sprechende Namen für häufige Umwandlungen und Prüfungen verwendet werden.

Parser und Partial Active Patterns

Partial Active Patterns zeichnen sich dadurch aus, dass sie partiell definiert sind. Dies wird durch die Verwendung des Option-Typs als Rückgabetyp ausgedrückt und im Namen durch einen abschließenden Unterstrich gekennzeichnet.

open System // Dort ist der Typ Int32 definiert
let (|AlsGanzzahl|_|) x =
  match Int32.TryParse(x) with
  | true, wert -> Some(wert)
  | _ -> None

let test =
  match "24" with
  | AlsGanzzahl x -> "die Ganzzahl " + string x
  | _ -> "keine Ganzzahl"

Als Nächstes zeige ich, dass die zwei Konzepte partielle Definition und Klassifikation kollidieren, insbesondere mit der beliebigen Kombinierbarkeit von Patterns: Die Variante (|X|Y|_|) darf (und kann glücklicherweise) nicht verwendet werden, wie folgendes hypothetisches Beispiel zeigt.
Im Folgenden wird auch auf die Ausführungsreihenfolge eingegangen, insbesondere auf den Zeitpunkt, wann die als Active Patterns definierten Funktionen auf den Wert angewendet werden.

open System // Dort sind die Typen Int32 und Double definiert
let (|Ganzzahl|Kommazahl|_|) x =
// Anm.: Dieser Funktionsname wird vom Parser nicht akzeptiert.
  match Int32.TryParse(x) with // Versuche Wert als Ganzzahl zu parsen:
  | true, wert -> Some(Ganzzahl(wert)) // OK: Ganzzahl
  | _ -> match Double.TryParse(x) with // Ansonsten als Kommazahl:
         | true, wert -> Some(Kommazahl(wert)) // OK: Kommazahl
         | _ -> None // Sonst: weder Ganz- noch Kommazahl

let test =
  match "24" with // führt (|Ganzzahl|Kommazahl|_|) aus,
                  // liefert Some(Ganzzahl(42))
  | Ganzzahl 42 -> "die Ganzzahl 42" // Scheitert bei match 24 with 42.
  | Kommazahl x -> "irgend eine Kommazahl" // Wird ignoriert, denn
    // die Zahl wurde als Ganzzahl, nicht als Kommazahl klassifiziert.
    // Intuitiv wäre ein erneutes Parsen, das Kommazahl(24.0) liefert.
  | _ -> "gar keine Zahl" // Dieser Fall trifft zu!

Stattdessen werden hier die kleinstmöglichen Einheiten, die als Partial Active Patterns definiert sind, (|Ganzzahl|_|) und (|Kommazahl|_|) verwendet, die sich erwartungsgemäß verhalten.

Diese Varianten stellen durch die Verwendung Klassifizierer dar, in jedem Fall aber sind es Parser.

open System // Dort sind die Typen Int32 und Double definiert
let (|Ganzzahl|_|) x =
  match Int32.TryParse(x) with
  | true, wert -> Some(Ganzzahl(wert))
  | _ -> None

let (|Kommazahl|_|) x =
  match Double.TryParse(x) with
  | true, wert -> Some(Kommazahl(wert))
  | _ -> None

let test =
  match "24" with
  | Ganzzahl 42 -> "die Ganzzahl 42" // Führt (|Ganzzahl|_|) aus,
  // liefert Some(24), scheitert bei match 24 with 42. Nächster Fall:
  | Kommazahl x -> "irgend eine Kommazahl" // Führt (|Kommazahl|_|),
  // liefert Some(24.0), trifft zu und bindet 24.0 an x.
  | _ -> "gar keine Zahl"

Übersicht der Anwendungsfälle


Durch diese Anwendungsfälle lassen sich folgende Nutzungen von Active Patterns herauskristallisieren:

(|X|) Konvertiere zu X (Konvertierer), Überprüfe auf Eigenschaft X (Validierer) und wirf eine Exception im Fehlerfall.
(|X|Y|) Klassifiziere nach Eigenschaften X, Y, … (bis zu 7 Eigenschaften sind möglich) (Klassifizierer)
(|X|_|) Klassifiziere nach Eigenschaft X oder scheitere (Klassifizierer), parse Wert als X (Parser)

Die Benutzung von Active Patterns kann zu verständlicherem Code führen, indem Pattern Matching damit auf beliebigen Datentypen benutzt werden kann.

Bearbeitet: Arbeit über Active Patterns referenziert.

In der Arbeit über Active Patterns werden unter anderem für häufig verwendete objektorientierten Typen wie Type und XmlDocument Active Patterns definiert, die eine Verwendung der Objekte dieses Typs wie Varianten eines algebraischen Datentypen zulässt [ActivePattern, vgl. S. 4, 7-8].

Ein Beispiel, das besonders durch Active Patterns deklarativ ist, sind diese drei Definitionen, die die Verarbeitung von XML-Dokumenten enorm erleichtert. Hier werden für die Typen der System.Linq.XObject-Hierarchie Active Patterns definiert. Das anschließende Beispiel zeigt, wie diese zu verwenden sind.

open System.Xml.Linq

// (|Node|_|): string -> XNode -> XNode seq
let (|Node|_|)(name: string)(node: XNode) =
  match node with
  | :? XElement as element
    when element.Name.LocalName = name ->
    Some(element.Nodes())
  | _ -> None
    
// (|Text|_|): XNode -> string option
let (|Text|_|)(node: XNode) =
  match node with
  | :? XElement -> None
  | _ -> Some(node.ToString())

// (|Attribute|_|): string -> XNode -> string option
let (|Attribute|_|)(name: string)(node: XNode) =
  match node with
  | :? XElement as element ->
    match element.Attribute(XName.Get(name)) with
    | null -> None
    | x -> Some(x.Value)
  | _ -> None

let rec traverseAll = Seq.iter traverseNode
and traverseNode = function
| Text text -> printfn "    %s" (text.Trim())
| Node "Matches" children -> traverseAll children
| Node "Match" children & Attribute "Winner" winner
  & Attribute "Loser" loser & Attribute"Score" score ->
  printfn "%s won against %s with score %s" winner loser score
  traverseAll children

traverseNode(XElement.Load("matches.xml"))

Für das Beispieldokument matches.xml:

<Matches>
  <Match Winner="A" Loser="B" Score="1:0">
    Description of the first match...
  </Match>
  <Match Winner="A" Loser="C" Score="1:0">
    Description of the second match...
  </Match>
</Matches>

erscheint diese Ausgabe:

A won against B with score 1:0
    Description of the first match...
A won against C with score 1:0
    Description of the second match...


Durch dieses Beispiel wird vor allem die Kompositionierbarkeit (Konjunktion mit &) von Active Patterns deutlich. Das folgende Muster passt genau auf einen Knoten Match mit den Attributen Winner, Loser sowie Score und extrahiert gleichzeitig Kindelemente des Knotens und die Attributwerte:

Node "Match" children & Attribute "Winner" winner & Attribute "Loser" loser & Attribute"Score" score

Dieser Ansatz führt zu einer weiteren Denkweise hinter deklarativer Programmierung: Domänenspezifische Sprachen (domain-specific languages, DSL). Die Regeln, die zuvor definiert wurden stellen eine interne DSL dar.

3.2.4 Computation Expressions

Technik: Computation Expressions
Zweck: Alternative Auswertung von F#-Konstrukten
Problem: Grundlegende Konstrukte wie Variablenbindungen und Schleifen werden standardmäßig sequenziell ausgeführt, ohne dass darauf Einfluss genommen werden kann. Eine parallele Ausführung, Logging, schrittweise-unterbrechbare Ausführung oder verzögerte Ausführung müssen explizit behandelt werden.
Lösung: Computation expressions bieten die Möglichkeit, über Continuations die Ausführung zu beeinflussen. Das primäre Konstrukt dafür ist der Computation Builder.
Performanz: Hängt von den Methoden des Builders ab; führt zusätzlich Funktionsobjekte für die Continuations ein.Continuations können in Einzelfällen zu Performanz-Problemen führen (z.B. http://www.quanttec.com/fparsec/users-guide/where-is-the-monad.html#why-the-monadic-syntax-is-slow).
Alternative: Alternative Ausführung muss explizit formuliert werden, was aufwendig oder lästig sein kann.

Um Computation Expressions zu verstehen, muss man die Funktionsweise des Computation Builders verstehen. Ein Computation Builder ist ein Objekt einer Klasse, die mindestens diese beiden Methoden besitzt:

Bind(value, continuation) Für das Konstrukt let! identifier = expression in body. Dies ermöglicht Kontrolle über Wertbindungen und die weitere Ausführung nach dieser Bindung.
Return(value) Für das Konstrukt return expression. Damit wird die Ausführung der Computation Expression beendet und liefert einen Wert des gesamten Ausdrucks der Computation Expression.

Ein häufiges Idiom in der imperativen Programmierung sind null-Prüfungen. Da in der funktionalen Programmierung null kein gültiger Wert eines Typs ist, wird der Option-Typ (siehe Option-Typ im Abschnitt Typen) verwendet. Die Intention des fehlenden Wertes wird dadurch deutlicher, anstatt für alle Referenz-Typ null als Wert zu erlauben.

Der Option-Typ enthält zwei Varianten: je eine Variante für einen undefinierten oder definierten Wert.

type Option<'a> = None | Some of 'a

Um mit diesem Typ zu arbeiten, muss mithilfe von Pattern matching unterschieden werden, ob Zwischenergebnisse definiert sind und ggf. die Berechnung mit dem undefinierten Wert zu beenden. Als Beispiel dient hier eine Funktion, die zwei Zahlen aus der Konsole liest und die Summe zurückgibt. Nur für den Fall, dass beide Eingaben Zahlen darstellen, ist das Ergebnis definiert.

open System
/// readIntegerOptionFromConsole: unit -> int option
let readIntegerOptionFromConsole() =
  match Int32.TryParse(Console.ReadLine()) with
  | true, value -> Some(value)
  | _ ->None

match readIntegerOptionFromConsole() with
| None -> None
| Some(firstValue) ->
  match readIntegerOptionFromConsole() with
  | None -> None
  | Some(secondValue) -> Some(firstValue + secondValue)

Da bei der Programmierung mit externen Datenquellen (wie etwa der Konsole, Dateien oder Webinhalten) diese Daten nicht immer ein gültiges Format haben, ist der Code, der mit diesen Daten arbeitet, mit Gültigkeits-Prüfungen versehen. Im Idealfall wird in objektorientierten Programmiersprachen mit Exceptions gearbeitet, sodass der korrekte Arbeitsablauf innerhalb eines Try-Konstrukts geschrieben werden kann und im Falle eines Fehlers die Fehlerbehandlung durchgeführt wird. In der Tat ließe sich diese Methode auch für das angeführte Beispiel verwenden:

open System
/// readIntegerFromConsole: unit -> int (throws FormatException)
let readIntegerFromConsole() = Int32.Parse(Console.ReadLine())

try
  let first = readIntegerFromConsole()
  let second = readIntegerFromConsole()
  Some(first + second)
with :? FormatException as ex -> None

In der funktionalen Programmierung ist jedoch die Verwendung des Option-Typs verbreiteter, weil schon über den Typ wie etwa int option ersichtlich ist, dass dieser Vorgang fehlschlagen kann. Bei Exceptions ist dies nur durch Dokumentation ersichtlich oder im Fall von Java mit checked exceptions, die zur Methodensignatur zählen und im verwendenden Code abgefangen werden müssen.

In beiden Fällen ist die Fehlerbehandlungsstrategie ersichtlich. Mithilfe von Computation Expressions ist eine alternative Auswertung möglich, sodass das Abfangen von Exceptions oder Prüfen auf definierte Werte ein Belang ist, der nicht explizit im Code wie oben formuliert wird, sondern Aufgabe des Computation Builders ist.

Im Fall des Option-Typs ließe sich der Option-Workflow definieren:

type OptionBuilder() =
  member this.Bind(value, continuation) =
    match value with
    | None -> None
    | Some(definedValue) -> continuation(definedValue)
  member this.Return(value) = Some(value)
let optional = OptionBuilder()

Dieser lässt sich dann wie folgt verwenden:

optional {
  let! first = readIntegerOptionFromConsole()
  let! second = readIntegerOptionFromConsole()
  return first + second
}

Der obenstehende Code benutzt die Methoden des OptionBuilder-Typs. Jedes Vorkommen von let! Pattern = Expression in Body (in kann auch durch einen Zeilenumbruch ersetzt werden) wird durch optional.Bind(Expression, fun Pattern -> Body) ersetzt. Ebenso wird return Value in optional.Return(Value) übersetzt.

Hier wird lediglich syntaktischer Zucker verwendet, der unter anderem Ähnlichkeit mit let-Bindungen hat und beim Kompilieren durch Methodenaufrufe des Computation Builders ersetzt wird.
Wichtige Beispiele dieser Technik sind seq für Sequenz-Literale, async für nebenläufige Programmausführung und query für Datenbank-Abfragen. Wie eingangs erwähnt, ist vereinfachte nebenläufige Programmausführung ein Vorteil von deklarativen Programmiersprachen. Dies wird insbesondere deutlich, wenn die Integration von nebenläufigen Methodenaufrufen durch einen Computation Builder komfortabler gemacht wird. Andere Sprachen greifen für solche Zwecke auf neue Schlüsselwörter, Syntax-Erweiterungen und Makros zurück. Auch in der Hinsicht ist eine selbstprogrammierbare alternative Ausführungsumgebung praktisch.

Insbesondere bei Datenbankabfragen ist es vorteilhaft, wenn der Programmierer keine SQL-Strings manipuliert, um eine Anfrage zu erstellen, sondern stattdessen in einer dafür erstellten Auswertungsumgebung Queries schreibt, die entsprechende Datenbank-Typen verwenden.

    let articles = query {
        for article in db.Articles do
            sortBy article.Price
            select (article.Name, article. Price)
    }
    for (name, price) in articles do printfn "%s costs %f €" name price

sortBy und select sind sogenannte Custom operations, die wie kontextabhängige Schlüsselwörter einer Programmiersprache wirken, jedoch nur spezielle Methoden des Computation Builders sind.

Im Fall des Query-Builders wird auch auf Quotations zurückgegriffen, die im nächsten Kapitel behandelt werden und den Einstieg in Metaprogrammierung darstellen.
Dazu wird im Computation Builder die Methode Quote eingeführt [FSharpSpec, S. 62].

3.3 Domänenspezifische Sprachen


Was sind DSLs?

Domänenspezifische Sprachen (domain specific languages, kurz DSLs) sind Sprachen, in denen nur Probleme eines Fachgebietes (einer Domäne) formuliert werden können. Aufgaben außerhalb des Anwendungsgebietes sollen nicht in DSLs gelöst werden. Dieser Punkt unterscheidet sie stark von generellen Programmiersprachen (general purpose languages, kurz GPLs), die alle programmierbaren Probleme darstellen können.

Man unterscheidet interne und externe DSLs. Interne sind solche, die innerhalb einer anderen Programmiersprache auftreten, also mit mitteln der Programmiersprache formuliert sind. Externe DSLs sind jene, die nicht die Mittel einer Host-Programmiersprache verwenden sondern eine eigene Syntax aufweist. Mit externen DSLs erstellte Texte (bzw. Skripte oder Beschreibungen) werden oft in externen (Text-)Dateien geschrieben, wobei es Ausnahmen wie SQL und Regex gibt, die auch in anderen Programmiersprachen als String-Inhalte verwendet werden.

Als Beispiel für eine interne DSL dient hier Miss Grant’s Controller [DSLs], ein Sicherheitssystem, das ein Fach öffnet, nachdem eine bestimmte Folge von Aktionen durchgeführt wurde. In F# werden die Aktionen, Zustandsnamen, Codes und Ereignisse als algebraische Datentypen definiert (im Original werden diese als Strings modelliert, was für externe DSLs sehr flexibel ist, für interne DSLs hingegen Typsicherheit wichtiger ist). Ein Zustand und das System selbst werden als Datensatz definiert. Die Konstruktion des Systems geschieht über Datensatz-Konstruktoren, Listenliterale und mithilfe von Operatoren.Eine Beispielprogramm, das den Nutzer durch den resultierenden Automaten dieses Systems navigieren lässt, findet sich im Anhang im Abschnitt Miss Grant’s Controller.

type condition = DoorClosed | DrawerOpened | LightOn
               | DoorOpened | PanelClosed
and actions = UnlockPanel | LockPanel | LockDoor | UnlockDoor
and codes = D1CL | D2OP | L1ON | D1OP | PNCL
          | PNUL | PNLK | D1LK | D1UL
and stateName = Idle | Active | WaitingForLight
              | WaitingForDrawer | UnlockedPanel
and state = {
    name: stateName;
    actions: actions list;
    transitions: (condition * stateName) list
}
and machine = {
    events : (condition * codes) list
    resetEvents: condition list
    commands : (actions * codes) list
    states : state list
}
 
let inline (=>) a b = (a, b)
let inline (:=) name (actions, transitions) =
    { name = name; actions = actions; transitions = transitions }
 
let machine = {
    events = [
                DoorClosed => D1CL
                DrawerOpened => D2OP
                LightOn => L1ON
                DoorOpened => D1OP
                PanelClosed => PNCL
    ];
    resetEvents = [ DoorOpened ];
    commands = [
                UnlockPanel => PNUL
                LockPanel => PNLK
                LockDoor => D1LK
                UnlockDoor => D1UL
    ];
     states = [
                Idle := [UnlockDoor; LockPanel]
                  => [DoorClosed => Active]
                Active := []
                  => [DrawerOpened => WaitingForLight;
                      LightOn => WaitingForDrawer]
                WaitingForLight := []
                  => [LightOn => UnlockedPanel]
                WaitingForDrawer := []
                  => [DrawerOpened => UnlockedPanel]
                UnlockedPanel := [UnlockPanel; LockDoor]
                  => [PanelClosed => Idle]
        ]
}

Die Verwendung von DSLs lässt sich auch als Teil von language-oriented programming ansehen, einem Paradigma, das darauf basiert, eine geeignete Notation zur Problembeschreibung zu entwickeln und die Software dann mit dieser Notation zu entwickeln. Dies wird in der Arbeit, die diesen Begriff maßgeblich geprägt hat, auch durch kürzeren Quellcode motiviert:

In computer science it is a great advantage to have a suitable notation in which to express certain classes of algorithms, rather then writing yards of source code. [LanguageOrientedProg, S. 9]

Reguläre Ausdrücke

Eine sehr beliebte externe DSL sind reguläre Ausdrücke (regular expressions, kurz regex), mit denen sich Text nach bestimmten Mustern durchsuchen lässt. Beispiele für Muster sind konkrete Buchstaben, Ziffern, Leerzeichen; hinter diese Mustern kann eine Vorkommens-Einschränkung notiert werden (z.B. einmal oder keinmal, mindestens einmal oder beliebig oft). Die Integration von regulären Ausdrücken in Programmiersprachen ist vielfältig. Hier soll mithilfe von Active Patterns eine möglichst intuitive Verwendung erreicht werden.

Regex über Active Patterns:

> open System.Text.RegularExpressions
let (|RegexGroups|_|) pattern text =
    let regex = Regex.Match(text, pattern)
    if regex.Success then
      Some(List.tail [ for group in regex.Groups -> group.Value ])
    else None;;

val (|RegexGroups|_|) : pattern:string -> text:string -> string list option

> match "12+13" with
  | RegexGroups "(\d+)\+(\d+)" [a; b] ->
      sprintf "Zwei Zahlen: %s und %s" a b
  | _ -> "keine zwei Zahlen";;

val it : string = "Zwei Zahlen: 12 und 13"

Weitere Techniken zur Programmierung von DSLs mit F# sind möglich, die hier nicht aufgezählt werden können. Einige werden in [RealWorldFP, vgl. S. 425, 433, 451] angesprochen und umgesetzt (neue Operatoren, Typ-Augmentation, Operator-Lifting). Genaueres zu Operatoren findet sich in [FSharp, S. 119]. Eine praxisnahe Übersicht über DSL-Techniken bietet https://github.com/dungpa/dsls-in-action-fsharp/blob/master/DSLCheatsheet.md.

DSLs und funktionale Programmiersprachen sind seit LISP engverwandt. Martin Fowler merkt in seinem Buch [DSLs, S. 163] an, nicht genug über DSLs und funktionale Programmierung zu wissen, um es in dem Buch darzustellen, weshalb sich das Buch auf DSL-Techniken für objektorientierte Programmiersprachen konzentriert.

Eine häufig anzutreffende Technik, die für objektorientierte interne DSLs verwendet wird, sind sogenannte Fluent Interfaces, d.h. Objekte, die Methodenketten erlauben, wodurch nacheinander Eigenschaften spezifiziert werden oder Aktionen ausgeführt werden. Um z.B. für eine Klasse mit zwei Feldern int x, y eine ToString-Methode zu schreiben, ließe sich der StringBuilder verwenden. Der Trick liegt darin, dass die Append-Methode dasselbe Exemplar zurückgibt, sodass die nächste Methode aufgerufen werden kann. Die letzte Zeile der Methode lautet also return this;.

class Point {
  public int X, Y;
  public override string ToString() {
    return new StringBuilder()
      .Append("[").Append(X)
      .Append(" | ").Append(Y)
      .Append("]").ToString();
  }
}

Im folgenden Kapitel geht es das Konzept Metaprogrammierung, das sich mit Programmerzeugung, -Analyse und -Transformation befasst, was für DSLs essenziell ist. Außerdem wird mit Quotations eine mächtige Technik für interne DSLs eingeführt.

3.4 Metaprogrammierung

Was ist Metaprogrammierung?

Für Metaprogrammierung gibt es verschiedene Definitionen und Erklärungen; die Folgenden stammen aus dem Buch [MetaprogDotNet].

  1. A computer program that writes new computer programs. [MetaprogDotNet, S. 6]
    • Code-Generierung ist in der Tat ein wichtiges Gebiet der Metaprogrammierung. Immerhin müssen Compiler den Quellcode der Programmiersprache in Maschinen-nahen Code umsetzen. Dennoch schreiben nur wenige Programmierer jemals selbst einen Compiler. Nur selten wird Code generiert, z.B. im Fall von Datenbank-Programmierung und der Generierung von Klassen aus dem Datenbank-Schema. Eine anderer anwendungsbezogener Aspekt von Metaprogrammierung ist Analyse oder Inspektion von Programmen (bzw. von Objekten) zur Laufzeit (dies ist das Gebiet Reflection von Programmiersprachen).
  2. Try to think of it [metaprogramming] as after-programming or beside-programming. The Greek prefix meta allows for both of those definitions to be correct. Most of the examples in this book demonstrate programming after traditional compilation has occurred, or by using dynamic code that runs alongside other processes. [MetaprogDotNet, S. 6]
    • Die Umschreibung mit Danach-Programmierung ist bei Codetransformation sehr passend, weil vom Benutzer geschriebener Code vor dem eigentlichen Kompilieren um Aspekte wie Persistenz von ObjektenWie etwa für das Serializable-Attribut bei der Programmiersprache Nemerle: http://nemerle.org/wiki/index.php?title=Macros_tutorial#Macros_in_custom_attributes. oder DatenprüfungenWie in Design-by-Contract-Frameworks für NotNull-Attribute. erweitert wird. Nebenbei-Programmierung kann das Arbeiten mit generiertem Code sein, d.h. beim Programmieren kann auf generierte Klassen und Methoden zugegriffen werden. Das ist insbesondere wichtig bei GUI-Programmierung, wenn GUI-Designer Code erzeugen, den der Programmierer sofort verwenden muss, z.B. Referenzen auf Steuerelemente; oder auch bei aus Datenbank-Schemata generierten Klassenbibliotheken.

Im Folgenden wird Metaprogrammierung anhand von Syntaxbäumen erklärt, weil diese auf anschauliche Weise zeigen, dass Programmcode Daten sind und die übliche Datenverarbeitung dadurch zur Verarbeitung von Programmen wird.

Quotations



Es kann vorteilhaft sein, auf Teile des Quellcodes als Objekt zugreifen zu können, z.B. um diesen zu analysieren, zu transformieren, zu persistieren oder zu übertragen. In F# sind Quotations Ausdrücke der Form <@ Ausdruck @>. Innerhalb dieser Klammern lässt sich Quellcode schreiben, der nicht ausgewertet oder kompiliert wird, sondern dessen Syntaxbaum erzeugt wird. Die Einschränkung ist, dass keine Typen und Module deklariert werden können. Wenn Funktionen geschrieben werden, lässt sich über des ReflectedDefinition-Attributes ausdrücken, dass auch auf die quotierte Form der Funktion zugegriffen werden kann, wie folgendes Beispiel zeigt:

> [<ReflectedDefinition>]
  let f(x: int) = 2 * x;;
val f : int -> int

> open Microsoft.FSharp.Quotations
  open Microsoft.FSharp.Quotations.Patterns
  open Microsoft.FSharp.Quotations.DerivedPatterns;;
> match <@ f @> with
  | Lambda(param,
           Call(target, MethodWithReflectedDefinition def, args)) -> def;;
warning FS0025: Incomplete pattern matches on this expression.
val it : Expr = Lambda (x,
  Call (None, Int32 op_Multiply[Int32,Int32,Int32](Int32, Int32),
        [Value (2), x]))
{CustomAttributes = ...;
 Type = Microsoft.FSharp.Core.FSharpFunc`2[System.Int32,System.Int32];}

Mithilfe von Quotations lassen sich F#-Ausdrücke möglich, die keinem typischen F#-Programm ähneln. Z.B. lässt sich das Member-Prolog-Prädikat bei geeigneter Definition von memb, E, __ und R in F# schreibenIm Abschnitt Quotations des Anhangs finden sich besagte Definitionen.. Dieses Programm ließe sich in den entsprechenden Prolog-Code transformieren. Dies ist ein Schritt in polyglotte (mehrsprachige) Programmierung, bei der man verschiedene kompatible Programmiersprachen zur Lösung eines Problems verwendet.

prolog <@
        memb(E, E :: __)
        memb(E, __ :: R) <-- memb(E, R)
@>

Für Codegenerierung sind Syntax-Bäume ein gutes Hilfsmittel. Andernfalls müsste man auf Generierung von Quelltext in Form von Strings zurückgreifen, wobei dies schnell zur Generierung von fehlerhaftem Code führen kann. Andere Aufgaben wie Code-Optimierung und -Transformation können nicht sinnvoll auf der Basis von Strings durchgeführt werden, weil Fallunterscheidungen anhand von Strings fehlerträchtig und aufwendig sind. Syntaxbäume werden z.B. bei der Überführung von Ausdrücken in der Programmiersprache in SQL-Befehle verwendet.

Bearbeitet: Code-Strings sind auf der falschen Abstraktionsstufe.

Metaprogrammierung und DSLs stehen in starkem Zusammenhang, in dem oben genannten Buch werden DSLs durch Metaprogrammierungstechniken ermöglicht [MetaprogDotNet, vgl. S. 5]

Quotations und Computation-Expressions werden oft für Metaprogrammierungszwecke eingesetzt. Ein beliebtes Beispiel sind Datenbank-Queries, die in SQL umgesetzt werden können.

query{ for customer in db.Customers do
         where customer.ID = 42 
         select customer.Name
}

Dieser Ausdruck kann innerhalb der Entwicklungsumgebung geschrieben werden, wobei nur gültige Abfragen formuliert werden können. Der Ausdruck kann in den SQL-Befehl select Name from Customers where ID = 42 übersetzt werden.

Mit Metaprogrammierung ist es möglich, von Computer-nahen Möglichkeiten zu abstrahieren. Das gilt insbesondere für konkrete Techniken der Fallunterscheidungen, die in den Abschnitten Pattern matching und Imperativ-objektorientierte Fallunterscheidungen betrachtet wurden. Damit wird die Aufgabe der Umsetzung auf einen späteren Zeitpunkt verschoben.

Somit kann die Ausführungsumgebung eine andere sein als die standardmäßig verwendete; dies wurde bereits mit einem F#-zu-JavaScript-Übersetzerhttp://fsharp.org/use/html5/ und Ausführung einer Untermenge von F#-Konstrukten auf Grafikkarten durchgeführt http://fsharp.org/use/gpu/. Details zu der GPU- und SQL-Übersetzung finden sich in [FSharpMeta, S. 48, 50].

4 Imperativer Stil



In diesem Teil geht es um die imperativen Pendants zu einigen vorgestellten deklarativen Elementen. Diese sind nicht nur deshalb wichtig, um mit Programmierern, die vorwiegend imperativ geprägte Programmiersprachen verwenden, über Quellcode zu reden und zu diskutieren. Die Details der Umsetzung deklarativer Elemente sind für Programmierer interessant, die eine Programmiersprache nicht nur verwenden sondern auch erweitern wollen oder sich für die technische Umsetzung interessieren.

Dieses Kapitel ist folgendermaßen strukturiert:

  • In dem Abschnitt Imperative Konsistenzprüfungen geht es um Veränderlichkeit von Daten und den damit einhergehenden Problemen und Maßnahmen.
  • Der Abschnitt Imperativ-objektorientierte Typen zeigt kurz, was bei der Definition von Datensatz-Typen in imperativ-objektorientierten Programmiersprachen zu beachten ist.
  • Im Abschnitt Imperativ-objektorientierte Fallunterscheidungen geht es um Möglichkeiten der Kontrollflussmanipulation. Neben der Durchführung von Berechnungen und Lese-/Schreiboperationen ist die Veränderung des Kontrollflusses eine der Hauptaufgaben des Prozessors. Dank der Idee von Fallunterscheidungen und Schleifen werden Sprungbefehle nicht vom Programmierer geschrieben, sondern vom Compiler. Nur Fallunterscheidungen, keine Schleifen werden hier betrachtet. Eine Evaluation der Techniken findet im darauffolgenden Kapitel Evaluation der Fallunterscheidungstechniken statt.

Motivation

Gängige Algorithmen sind oft in Pseudocode notiert (wie etwa in [Cormen]) und werden vorwiegend mit imperativ geprägten Sprachen implementiert. Vor allem Arrays werden für effiziente Algorithmen verwendet. Für andere Anwendungsgebiete wie Matrizen-Rechnungen oder die Initialisierung von komplexen Datenstrukturen eignet sich die imperative Herangehensweise, was vor allem durch Performance-Verbesserungen motiviert wird [FSharp, vgl. S. 49].

In F# lassen sich auch imperative Konstrukte wie while oder for benutzen, jedoch ist das Verlassen einer Schleife mit einem Sprungbefehl (wie return oder break) nicht möglich. Die Verwendung von if then else ist grundsätzlich nicht imperativ; sie wird hier jedoch als solche gezählt, da sie in Form des If statements aus der imperativen Programmierung besonders häufig auftritt.

Es folgt als Beispiel eine vereinfachte Version des Algorithmus counting sort [Cormen, vgl. S. 194-195], der Ganzzahlen in einer Laufzeit von \mathcal{O}(n) sortiert. Der Code ist in F# geschrieben und ist ein gutes Beispiel für ein effizienten imperativen Algorithmus. Zuweisungen in F# werden mit dem Pseudocode-Pfeil <- notiert; Zuweisungen von veränderbaren Variablen (die mit let mutable deklariert wurden) und von Array-Elementen sind erlaubt.

Allein durch die Verwendung von Funktionen und Operationen kann ermittelt werden, dass dieser Algorithmus auf Integer-Arrays arbeitet (int []).Dieser Algorithmus funktioniert auf Arrays mit relativ kleinen Zahlen sehr gut. Der zusätzliche Speicherbedarf ist linear zum Maximum der Zahlen. Außerdem dürfen keine negativen Zahlen vorkommen. Eine Variante, die erweiterte, mit Haskell vergleichbare Generizität nutzt, ist im Anhang im Abschnitt Counting Sort zu finden. Die dortige Variante funktioniert mit allen Ganzzahltypen (byte, short, int, long, BigInteger); die eben genannten Voraussetzungen bleiben jedoch bestehen.

> let SortInPlace numbers =
    let maximum = Array.max numbers
    let occurences = Array.zeroCreate(maximum + 1)
    for num in numbers do
        occurences.[num] <- occurences.[num] + 1
    let mutable insertionIndex = 0
    for num = 0 to maximum do
        for times = 1 to occurences.[num] do
            numbers.[insertionIndex] <- num
            insertionIndex <- insertionIndex + 1
    numbers;;

val SortInPlace : numbers:int [] -> int []

> SortInPlace [|1; 2; 3; 4; 13; 7|];;
val it : int [] = [|1; 2; 3; 4; 7; 13|]

Das Kompilieren dieses Codes erzeugt eine statische Klasse CountingSort mit einer statischen Methode SortInPlace, die ein int[] in-place sortiert. Das Kompilat kann aus jeder .NET-Sprache heraus verwendet werden.

4.1 Imperative Konsistenzprüfungen


Fehlende Konsistenzprüfungen sind eine gefährliche Fehlerquelle; täglich werden Patches bereitgestellt, bei denen Sicherheitslücken oder Programmabstürze durch Konsistenzprüfungen vermieden werden (häufige Fehler sind fehlende Längen-Prüfung oder Null-Checks).

In der Tat obliegt es in der imperativ-objektorientierten Programmierung dem Programmierer, seine Methoden mit Konsistenzprüfungen zu versehen, die sicherstellen, dass Parameter von Referenz-Typen nicht null sind und dass Arrays und Strings die richtige Länge haben, um darauf zu arbeiten. Ein Denkmodell, das diese Prüfungen konsequent fordert und explizit Vor- und Nachbedingungen für Methoden verlangt, ist das Vertragsmodell (Design by contract).
Neben Parameterprüfungen, insbesondere auf Null-Werte, benötigt man Konsistenzprüfungen, die sicherstellen, dass sich eine Datenstruktur in einem gültigen Zustand befindet. Dies ist insbesondere wegen einer Eigenschaft von imperativ-orientierten Datenstrukturen notwendig: Veränderlichkeit.

Obwohl Felder und Einträge einer Datenstruktur geändert werden können, gibt es meistens Invarianten, die angeben, in welchem Rahmen Änderungen zu einem korrekten Nachfolgezustand führen. Beispielsweise muss bei der Arbeit mit Suchbäumen, die auf veränderbaren Pointern basieren, darauf geachtet werden, dass konsequent alle Pointer geändert werden, um die Suchbaumeigenschaften des Baumes nicht zunichte zu machen.
Programmierdisziplin ist das Stichwort, das sich z.B. auch auf saubere Arbeit mit Pointern bezieht. Ein Kommentar dazu aus einem funktionalen Lehrbuch: Bei imperativen Sprachen muss man nahezu beliebige Konglomerate von untereinander verzeigerten Zellen managen, was auch bei größter Selbstdisziplin zu komplexen Fehlern führt. [FunktProg, S. 235].

Imperative Programme sind vor allem durch Veränderlichkeit schnell, genauer gesagt durch selektive Änderung (selective update) [FunktProg, S. 236]. Eine mögliche Sichtweise auf den Zusammenhang zwischen funktionaler Sicherheit und imperativer Effizienz ist in Abbildung # dargestellt.

funktionaleimperativewelt
Funktionale Qualität und imperative Effizienz als gegensätzliche Enden eines Spektrums [FunktProg, S. 236].

Konsistenzprüfungen sind eine Technik, um qualitative Software zu schreiben. Es gehört zum defensiven Programmierstil, einem weiteren qualitätsbewussten Denkmodell, die Integrität von Parametern zu prüfen, bevor auf ihnen gearbeitet wird.

Zwei bekannte Beispiele, welche die Gefahr von fehlenden Prüfungen deutlich zeigen, sind der Ariane-5- und der Mars-Climate-Orbiter-Unfall:

  • Im Falle des Ariane 5 Flight 501 wurde eine Überlaufprüfung für die horizontale Beschleunigung vergessen (die interessanterweise für die vertikale Beschleunigung durchgeführt wurde).
  • Im Falle des Mars-Climate-Orbiter-Unfalls haben zwei Entwicklerteams mit unterschiedlichen Maßeinheiten gearbeitet, der SI-Einheit Newton im einen und Pound-Force im anderen Team.

Gerade für solche Anwendungen ist Code-Qualität von enormer Wichtigkeit. In modernen Programmiersprachen gibt es beispielsweise Festkommazahlen mit hoher Genauigkeit und Langzahlarithmetik (big num) mit beliebiger Genauigkeit. Andererseits gibt es Maßeinheiten (units of measurement), damit statt auf einfachen Zahlen zur Entwicklungszeit mit SI-Einheiten gearbeitet werden kann.

4.2 Imperativ-objektorientierte Typen

Die wichtigsten Arten von Typen habe ich im gleichnamigen Abschnitt eingeführt. An dieser Stelle werde ich nur die Definition von Datensatz-Typen behandeln, d.h. Typen, die nur als Datenbehälter fungieren. Dazu verwende ich die Sprache C#, die imperativ-objektorientiert geprägt ist.

Schon bei diesen einfachen Typen stellen sich Fragen, wie ein solcher Type zu definieren ist, was insbesondere mit der Verwendung des Typen zusammenhängt. Für einen veränderlichen Punkt im zweidimensionalen Raum darstellt, könnte die einfachste Typ-Definition lauten: struct Punkt { public double X, Y; }.

Viele Designentscheidungen werden allein durch diese kurze Definition getroffen:

  • Das Schlüsselwort struct gibt an, dass der Typ nicht auf dem Heap sondern auf dem Stack alloziert wird. Das bedeutet, dass der Garbage Collector Exemplare dieses Typs nicht abräumen muss, sondern diese beim Verlassen des Geltungsbereichs der Variable gelöscht werden. Zuweisungen von Variablen (lokale Variablen, Felder, Parameter) führen zur Kopie des Exemplars. Es können keine Subtypen von Structs erstellt werden.
  • Der Typ enthält zwei Felder vom Typ double, d.h. Gleitkommazahlen mit doppelter Genauigkeit (64 Bit).

Mindestens genauso wichtig sind die Designentscheidungen, die durch das Auslassen von Methoden und Interfaces und Attributen getroffen wurden:

  • Der Typ besitzt keinen Konstruktor, der die Felder initialisiert.
  • Der Typ ist nicht als serialisierbar gekennzeichnet.
  • Der Typ verwendet unter Umständen eine ineffiziente Equals-Methode.
  • Der Typ besitzt keine sinnvolle ToString-Implementierung.

Die Folgen sind noch drastischer, wenn statt struct das Schlüsselwort class verwendet wird (class Punkt { public double X, Y; }):

  • Der Typ wird auf dem Heap alloziert, somit ist jede Variable vom Typ Punkt eine Referenz auf ein Objekt, das sich an einer Speicheradresse befindet. Das führt zu Aliasing-Effekten, d.h. Änderungen an einem Objekt hinter einer Referenz werden auch bei anderen Referenzen auf dasselbe Objekt sichtbar. Außerdem wird der Garbage Collector beansprucht, wenn Exemplare des Typs nicht mehr verwendet werden.
  • Eine Methode zum Kopieren eines Objektes ist gegebenenfalls auch sinnvoll und müsste implementiert werden. Bei möglicher Unterklassenbildung wird dies erschwert.
  • Der Typ besitzt keine sinnvolle Standardimplementierung der Equals-Methode, denn es wird auf Gleichheit von Speicheradressen geprüft, was dazu führt, dass zwei Punkte a und b mit denselben Koordinaten (d.h. a.X == b.X und a.Y == b.Y) nicht a.Equals(b) erfüllen). Die Equals-Methode muss von Hand programmiert werden. Bei möglicher Unterklassenbildung wird die korrekte Implementierung erschwert.
  • Die Verwendung des ==-Operators (sowie !=) verwenden nicht die Equals-Methode sondern prüfen Speicheradressen. Der Gleichheits-Operator (sowie Ungleichheits-Operator) kann für den Datensatz-Typ definiert werden.
  • Der Typ kann als Oberklasse dienen, d.h. es können von Punkt abgeleitete Klassen erstellt werden. Dieses Verhalten kann mit dem Schlüsselwort sealed unterbunden werden.

Wenn also sinnvoll mit Datensatz-Typen gearbeitet werden soll, müssen diese Probleme gelöst werden. Dazu müssen der Konstruktor und folgende Methoden implementiert werden: Equals, GetHashCode, ToString und eventuell Clone. Außerdem kann das Serializable-Attribut an die Typdefinition geschrieben werden, um anzugeben, dass der Typ serialisierbar ist. Sollen noch Konsistenzprüfungen für die Felder eingebaut werden, müssen die Felder durch Properties gekapselt werden. Für einige Typen sind eventuell Vergleichsrelationen wie < gewünscht, weshalb die im IComparable-Interface definierte Methode CompareTo implementiert werden kann (und bei Bedarf die Operatoren <, <=, >, >= implementiert werden können).

Es ergeben sich also allein für Datensatz-Typen eine Liste von Anforderungen, die erfüllt werden müssen, damit der Typ korrekt verwendet werden kann. Der angedeutete Code, der die oben angeführten Punkte erfüllt, muss für jeden Typ sinnvoll neu implementiert werden, was zu Boilerplate-Code führt. Im Fall von komplexeren Typen, die nicht nur Datensätze darstellen und in einer Klassenhierarchie stehen, ergeben sich viele weitere Anforderungen.

Diese Belange (Vergleich, Persistenz, Verwendung von Operatoren, Verwendung in Klassenhierarchien) sind für objektorientierte Programmierer Voraussetzung, um verwendbare Typen zu schreiben.

Modellieren einer festen Anzahl an Varianten


Soll eine feste Anzahl an Varianten in einer objektorientierten Programmiersprache definiert werden, kann dies mithilfe von Sichtbarkeitsmodifizierern für Konstruktoren erreicht werden. Unterklassenbildung ist mit Konstruktorverkettung verbunden, was in diesem Fall ausgenutzt wird.

  • Markieren des Konstruktors als private: Nur innere Klassen können aufgrund der Sichtbarkeitsregel für private Unterklassen werden. Dies entspricht dem typesafe enum pattern [EffectiveJava]:
    public abstract class CollectionFactory<T>
    {
        private CollectionFactory() { }
        public abstract ICollection<T> Create();
    
        class ArrayListFactory : CollectionFactory<T>
        { public override ICollection<T> Create()
          { return new List<T>(); } }
        public static readonly CollectionFactory<T>
          ArrayList = new ArrayListFactory();
    
        class LinkedListFactory : CollectionFactory<T>
        { public override ICollection<T> Create()
          { return new LinkedList<T>(); } }
        public static readonly CollectionFactory<T>
          LinkedList = new LinkedListFactory();
    }
    
  • Markieren des Konstruktors als internal: So können nur Klassen desselben Kompilats (die also im selben Projekt kompiliert werden) auf ihn zugreifen:
    public abstract class CollectionFactory<T>
    {
        internal CollectionFactory() { }
        public abstract ICollection<T> Create();
    }
    
    public class ArrayListFactory<T> : CollectionFactory<T>
    { public override ICollection<T> Create()
      { return new List<T>(); } }
    
    public class LinkedListFactory<T> : CollectionFactory<T>
    { public override ICollection<T> Create()
      { return new LinkedList<T>(); } }
    

Bezug zu Typ-Definitionen in F#

Datensatz-Definitionen (und Algebraische-Datentyp-Definitionen) in F# erfüllen bereits standardmäßig viele dieser Punkte: strukturelle Gleichheit, d.h. Equals unter Berücksichtigung aller Felder wird automatisch generiert, ebenso GetHashCode; struktureller Vergleich (CompareTo) wird generiert (Felder werden nacheinander verglichen, beim ersten Unterschied steht das Vergleichsergebnis fest); ein Konstruktor wird erzeugt; der Typ wird als serialisierbar gekennzeichnet.

Was die Verwendung des Typen angeht, wurde einerseits bereits auf das Pattern matching auf Datensätzen eingegangen. Zudem werden die Vergleichsoperatoren =, <> (<> steht für ungleich) in Equals-Aufrufe und <, <=, >, >= in Aufrufe der CompareTo-Methode umgewandelt.

Ein Nachteil bei Datensätzen in F# ist die Einschränkung, dass Datensätze zu Klassen kompiliert werden und nicht wahlweise zu Structs. Das kann in einigen Fällen zu unnötiger Beanspruchung des Garbage Collectors führen, insbesondere bei großen Datenmengen.

Structs

Ein kleiner Test soll dies veranschaulichen. Es werden Datencontainer für zweidimensionale Punkte erstellt, deren Komponenten Ganzzahlen 32-Bit-Genauigkeit sind. Eine Typ-Definition, die eine Datensatz-Klasse definiert, und eine, die einen explizit Structs erzeugt. Als einzige Operation darauf ist die Multiplikation mit einem Skalar definiert, die einen neuen Punkt mit multiplizierten Koordinaten erzeugt.

> #time;;
--> Timing now on
> type Pos = { X: int; Y: int }
    with static member (*)(p: Pos, s: int) =
           { X = p.X * s; Y = p.Y * s }

  [<Struct>]
  type PosS =
    val X: int
    val Y: int
    new(x, y) = { X = x; Y = y }
    static member (*)(p : PosS, s) = PosS(p.X * s, p.Y * s);;
...
> let erzeugeObjekte =
    let ausgangsArray = Array.init 1000000 (fun i -> { X = i * 4 + 3; Y = i / 2 })
    let gemappt = Array.map(fun p -> p * 13) ausgangsArray 
    "Ende des Testes";;
Real: 00:00:00.492, CPU: 00:00:00.265, GC gen0: 6, gen1: 3, gen2: 0
...
> let erzeugeStructs =
    let ausgangsArray = Array.init 1000000 (fun i -> PosS(i * 4 + 3, i / 2))
    let gemappt = Array.map(fun p -> p * 13) ausgangsArray 
    "Ende des Testes";;
Real: 00:00:00.015, CPU: 00:00:00.015, GC gen0: 0, gen1: 0, gen2: 0
...

Die Zeitmessung hinter Real gibt die gemessene Zeit zwischen Ausführungsanfang und -ende an. Die Einträge nach GC geben die Anzahl der Garbage Collections an, die durchgeführt wurden.

Für den Objekt-Test: 492 ms, 6 Generation-0-Garbage-Collections, 3 Generation-1-Garbage-Collections (9 GCs insgesamt).
Für den Struct-Test: 15 ms, keine Garbage Collection.

Die genaue Zeit und Anzahl von Garbage Collections ist von mehreren Faktoren abhängig. Garbage Collections sollten bei Performanz-kritischen Anwendungen vermieden werden, weil die Ausführung des eigentlichen Programmcodes während einer solchen pausiert wird und für die Laufzeit nachteilige Effekte auftreten, die mit Speicher- und Datenmanagement (Lokalitätseigenschaft) zu tun haben.
Auffällig ist aber, dass im Falle der Structs keine Garbage Collection durchgeführt wurde, weil dort nur zwei Objekte, die beiden Arrays erzeugt wurden. Im Gegensatz dazu wurden im anderen Test zwei Millionen Pos-Objekte erstellt (eine Million für das Ausgangs-Array und eine Million nach durchgeführter Multiplikation).

Es lohnt sich also, Structs verwenden zu können, auch wenn dadurch auf deklarative Typ-Definitionen und -Operationen verzichtet werden muss. In diesem Zusammenhang muss auch bedacht werden, dass das Verwenden einer Liste zur Erzeugung von vielen Cons-Zellen-Objekte führen kann (z.B. werden für [0..1000000] 1000000 Conszellen erzeugt). Mit Messungen und Programmcodeanalyse kann auf diese Aspekte eingegangen werden.

4.3 Imperativ-objektorientierte Fallunterscheidungen


Fallunterscheidungen sind ein zentrales Element der Programmierung. Deshalb ist es wichtig, die Möglichkeiten zu kennen, um die beste auszuwählen und gleichzeitig einzuschätzen, welche Folgen deren Benutzung hat.

Im Abschnitt Pattern matching wurde auf das gleichnamige Konstrukt eingegangen. Es ist nicht verwunderlich, dass diese Ausdrücke in Code niedrigerer Abstraktion umgewandelt werden müssen, um vom Computer durchgeführt werden zu können. Pattern matching wird in switch-Aufrufe umgewandelt sofern dies möglich ist.

Mittel der Fallunterscheidungen reiner imperativer Programmierung

if then else Dieses Konstrukt ist geeignet, wenn ein Code-Block abhängig von einer Bedingung hinter if in Form eines Bool’schen Ausdrucks ausgeführt werden soll. Der Block hinter then wird ausgeführt, wenn der Wert der Bedingung true ist, ansonsten wird die Alternative hinter else ausgeführt. Durch Schachtelung und Verkettung können beliebig komplexe Entscheidungsbäume programmiert werden, wobei ab einer schwer überschaubaren Größe von Spaghetti-Code [InformatikLexikon, S. 842] die Rede ist.
Ternärer Operator ? : Eine Variante von if then else, mit dem ternärem Operator Bedingung ? Folge : Alternative geschrieben wird, Ausdrücke aufnimmt und einen Ausdruck produziert.
Switch Mit dem Konstrukt switch wird eine Sprungtabelle aufgebaut, die insbesondere dann sinnvoll ist, wenn als Werte Ganzzahlen verwendet werden.
Try-Methoden Methoden mit mehreren Rückgabewerten werden gelegentlich über sogenannte Out-Parameter verwendet. Ein eingängiges Beispiel ist die DivRem-Methode, die den ganzzahligen Quotienten und Divisionsrest zurückgibt:
int DivRem(int a, int b, out int rem) { rem = a % b; return a / b; }
Verwendet wird dies in C# wie folgt:
int rem; int quotient = DivRem(21, 5, out rem); // quotient = 4, rem = 1
In F# ist die Nutzung von veränderbaren Variablen zwar möglich, sollte aber für solche eigentlich reinen Funktionen, die lediglich mehrere Rückgabewerte liefern, nicht verwendet werden. Daher können Out-Parameter wie zusätzliche Rückgabewerte behandelt werden:
let rem, quotient = DivRem(21, 5)
Wenn das Ergebnis partiell definiert ist, lässt sich über einen Bool’schen Rückgabe dies mitteilen. Das bereits verwendete Beispiel ist folgende in dem Typen int definierte Methode:
static bool TryParse(string text, out int result)
Try-Methoden entsprechen dem Pattern matching am ehesten, weil sowohl eine Unterscheidung der Fälle als auch eine Bindung von Variablen durchgeführt wird.

Mittel der imperativ-objektorientierten Programmierung

Subtyp-Polymorphie Im Vergleich zum Pattern matching steht die Funktionalität in verschiedenen Klassen, die jeweils den Fall für den eigenen Typ behandelt, anstatt in einer Funktion, welche die Typen (Varianten des algebraischen Datentyps) unterscheidet und somit alle Fälle behandelt.

Die konkreten Klassen besitzen einen gemeinsamen Obertyp und implementieren oder überschreiben eine Methode. Das im Abschnitt Klasse erwähnte dynamische Binden bezieht sich in gängigen objektorientierten Programmiersprachen auf Single Dispatch, d.h. die Operation hängt vom Typ des Empfängers ab. Diese Vorgehensweise ist in der Objektorientierung zentral, insbesondere für Parameter einer Methode den passenden Obertyp zu wählen. Damit wird nur auf die Schnittstelle, nicht auf eine konkrete Implementierung, hin implementiert.

Entwurfsmuster Besucher (Visitor) Das Entwurfsmuster Besucher (auch unter Visitor bekannt) [Entwurfsmuster, S. 269] benutzt den Double-Dispatch-Mechanismus. Bei Double Dispatch hängt die Operation von den Typen zweier Empfänger ab [Entwurfsmuster, S. 277]. Sprachen wie CLOS verwenden Multiple Dispatch, bei dem die Operation vom Typ des Empfängers und den Typen aller Parameter abhängt.

Wann ist welche Technik zu benutzen?

Die gerade genannten Techniken sollen im Abschnitt Evaluation der Fallunterscheidungstechniken in einem überschaubaren Beispiel gegenübergestellt werden.
Es geht um einen Interpreter, der einfache Ausdrücke auswertet, die aus Funktionsapplikation, Variablenbindung, Fall-Unterscheidung und Lambda-Ausdrücken bestehen.

Die vollständige Implementierung findet sich im Anhang im Abschnitt Beispiel Evaluator.

Eine Übersicht über die Techniken gibt das Diagramm #.

fallunterscheidungen
Entscheidungsbaum für Fallunterscheidungen.
Bearbeitet: Baum ist symmetrischer.

5 Evaluation der Fallunterscheidungstechniken


Wie im Abschnitt Imperativ-objektorientierte Fallunterscheidungen erwähnt, gibt es mehrere Möglichkeiten, Fälle zu unterscheiden und die Anwendungs-Logik für jeden Fall zu programmieren.
Ich habe diese Konstrukte und Techniken genannt:

  • if then else und ternärer Operator ? :
  • switch
  • Try-Methoden
  • Polymorphie
  • Visitor
  • Pattern matching

Das folgende Beispiel soll diese Techniken in Aktion zeigen und Vor- und Nachteile am Quellcode konkretisieren. Der gesamte Quellcode findet sich im Anhang im Evaluator-Abschnitt.

Es geht um die Implementierung eines einfachen Interpreters/Evaluators, der einfache Ausdrücke auswertet, die aus Funktionsapplikation, Variablenbindung, Fall-Unterscheidung und Lambda-Ausdrücken bestehen. Unter Verwendung der Scheme-Sytax geht es um Ausdrücke der folgenden Form:

  • Konstante, z.B. -15, 0, 42, true, false
  • Variable, z.B. x, eineVariable
  • Fallunterscheidung (if Dann Sonst)
  • Bindung (let ([Variablenname Wert]) Ausdruck)
  • Lambda-Ausdruck (lambda (Parameter1 Parameter2 ...) Ausdruck)
  • Applikation (Funktionsausdruck Argument1 Argument2 ...)
  • Vordefinierte Funktionen +, =, <

Im Anhang finden sich ebenfalls Test-Klassen, welche die Konstrukte testet. Dazu wird auf dynamische Typisierung (dynamic in C#) zurückgegriffen, da sich die verschiedenen Implementierungen keine gemeinsame Schnittstelle teilenDas wäre über diverse Interfaces wie IBinding<T> möglich gewesen, hätte aber die Implementierungen ein wenig umfangreicher gemacht.. Da die Struktur in allen Klassen dieselbe ist, können Ausdrücke in der Test-Klasse mithilfe von Konstruktoren der Typparameter (über das Constraint where T: new()) und Feldzuweisungen (etwa variable.Name = "x") Ausdrücke zusammengesetzt werden.

Ich fange mit der deklarativen Definition der Typen in F# an:

/// Stellt einen Ausdruck oder ein Ergebnis einer
/// simplen Programmiersprache dar.
type Code =
/// Number(Konstante Ganzzahl)
| Number of int
/// Bool(Konstanter Wahrheitswert)
| Bool of bool
/// Var(Name)
| Var of string
/// Binding(Name, Wert, Ausdruck)
| Binding of string * Code * Code
/// Conditional(Bedingung, Folge, Alternative)
| Conditional of Code * Code * Code
/// Application(Funktion, Argument-Liste)
| Application of Code * Code list
/// Lambda(Parameter-Namen, Ausdruck)
| Lambda of string list * Code
/// Closure = Lambda + Variablenbindungen
| Closure of Map<string, Code> * string list * Code
/// BuiltInFunc(F#-Funktion) (die Funktion erhält
/// ausgewertete Argumente)
| BuiltInFunc of (Code list -> Code)

Die Bedeutung der Daten, die den einzelnen Varianten zugeordnet sind, lässt sich aus der reinen Definition nur schwer ablesen. Deshalb steht dies in der Dokumentation der Varianten. Bei Pattern matching ist darauf zu achten, dass den Variablen, an welche die Datenfelder gebunden werden sprechende Namen gegeben werden (z.B. Binding(name, value, body) statt Binding(x, y, z)).

Pattern matching

Der Evaluator in F# basiert auf Pattern matching und verwendet immutable maps zur Speicherung von Variablenbindungen.

module Evaluator =
    let rec eval env expr =
        match expr with
        | Number _ | Bool _ | BuiltInFunc _ | Closure _ -> expr
        | Lambda(param, body) -> Closure(env, param, body)
        | Var name -> Map.find name env
        | Binding(name, value, body) ->
            eval (Map.add name (eval env value) env) body
        | Conditional(condition, thenExpr, elseExpr) ->
            match eval env condition with
            | Bool false -> eval env elseExpr
            | _ -> eval env thenExpr
        | Application(func, args) ->
            match eval env func with
            | Closure(extendedEnv, names, body) ->
                let addToMap map (key, value) = Map.add key value map
                let newEnv =
                  List.fold addToMap extendedEnv
                    (List.zip names (List.map(eval env) args))
                eval newEnv body
            | BuiltInFunc(func) ->
                func(List.map(eval env) args)
            | other -> failwithf "Only closures and built-in functions can be applied, found: %A" other
        
    let Evaluate(expr) = eval Map.empty expr

Die Funktionsweise des Evaluators ist leicht erklärt:

  1. Number ...: Ein konstanter atomarer Wert (Zahl oder Wahrheitswert) oder eine Funktion wird unausgewertet zurückgegeben.
  2. Lambda: Ein Lambda-Ausdruck wird mit allen bis dahin erzeugten Variablenbindungen als Closure zurückgegeben.
  3. Var: Eine Variable wird in den Variablenbindungen nachgeschlagen. Es kommt zu einem Laufzeitfehler, wenn der Wert zum Variablenbezeichner nicht gefunden wurde.
  4. Binding: Eine Variablenbindung wird hergestellt und der Code nach der Bindung wird ausgeführt.
  5. Conditional: Die Bedingung wird ausgewertet: Ist sie falsch (Bool false), wird der Alternativ-Zweig ausgewertet; alles außer falsch wird als wahr interpretiert und führt zur Auswertung des Folge-Zweiges.
  6. Aplication: Der Funktionsausdruck wird ausgewertet:
    1. Closure: Ist er eine Closure, werden die Argumente mit den aktuellen Variablenbindungen ausgewertet. Diese werden an die Parameter innerhalb der zusätzlichen Closure-Variablenbindungen gebunden und der Körper der Funktion wird mit diesen Bindungen ausgewertet.
    2. BuiltInFunc: Ist er eine eingebaute Funktion, wird diese auf die ausgewerteten Argumente angewendet.
    3. Sonst: Ist der ausgewertete Ausdruck keine Funktion, gibt es einen Laufzeitfehler, der darauf hinweist, dass der zu applizierende Ausdruck ein Funktionsausdruck sein muss.

Pattern matching hat den großen Vorteil, dass es intuitiv zu verwenden ist. Die Erweiterung um neue Fälle wurde bereits durch die Algebraische-Datentyp-Definition insofern eingeschränkt, als dass der einzige Erweiterungspunkt die eingebauten Funktionen (BuiltInFunc) sind. Diese enthalten eine Funktion, die zusätzliche Funktionalität enthält. Dies ist Komposition auf der Ebene algebraischer Datentypen und wird zum Ende des Kapitels noch einmal zusammengefasst.

In [SICP, vgl. S. 120] werden Scheme-Typen durch diese Funktionen definiert:

  1. Konstruktor, z.B. (erzeuge-punkt x y)
  2. Selektor, z.B. (punkt-x einPunkt) und (punkt-y einPunkt)
  3. Typ-Prädikat, z.B. (punkt? einPunkt)

Die Forderungen für diese Funktionen sind:

(punkt-x (erzeuge-punkt x _)) = x
(punkt-y (erzeuge-punkt _ y)) = y
(punkt? (erzeuge-punkt _ _)) = true

Dies hat den Vorteil, dass nur diese Funktionen zur Verfügung stehen müssen und die interne Repräsentation der Datenstrukturen dahinter verborgen wird. So wird eine starke Repräsentationsflexibilität erreicht. In imperativ-objektorientierten Programmiersprachen kann dies z.B. auch mit Interfaces erreicht werden, die nur Selektor-Methoden (Getter) bereitstellen. In objektorientierten Systemen sind Interfaces für reine Datenklassen nicht sehr üblich, dieselbe Flexibilität kann mit ihnen dennoch dargestellt werden:

  1. Konstruktor, z.B. new Punkt(x, y), wobei Punkt das Interface IPunkt implementiert
  2. Selektoren, z.B. interface IPunkt { int X { get; } int Y { get; } }
  3. Typ-Prädikat, z.B. einPunkt is IPunkt

Die Forderungen sind analog:

new Punkt(x, _).X = x
new Punkt(_, y).Y = y
new Punkt(_, _) is IPunkt

Mit algebraischen Datentypen und Pattern matching fallen diese Schritte zum intuitiven Muster und Konstruktor zusammen, bieten dadurch allerdings keine Repräsentationsflexibilität.

  1. Der algebraische Datentyp type Punkt = Punkt of int * int führt zum Muster (= Typ-Prädikat + Selektor) und Konstruktor Punkt(x,y).
  2. Der Datensatztyp type Punkt = { X: int; Y: int } führt zum Muster und Konstruktor { X = x; Y = y }.
  3. Der Tupeltyp int * int besitzt das Muster und den Konstruktor (x,y).

Auf dieselbe Weise, mit der in Scheme dem Programmierer Konstruktoren und Selektoren über ein Modul zur Verfügung gestellt werden müssen, kann auch ein Active Pattern (|Punkt|) zur Verfügung gestellt werden, das einen nicht näher spezifizierten Typen ^a in ein Tupel int * int umwandelt.

let inline (|Punkt|)(p: ^a) =
    let x = (^a: (member get_X: unit -> int) p)
    let y = (^a: (member get_Y: unit -> int) p)
    (x, y)

Dieser Typ muss die Properties X und Y vom Typ int besitzen. Sofern dies vom Typsystem nachgewiesen werden kann, lässt sich dieses Muster als Selektor verwenden. Der Konstruktor kann wie im objektorientierten Fall eine Klasse mit entsprechenden Properties sein.

Repräsentationsflexibilität in F# kann mit objektorientierten Interfaces oder mit generischen Funktionen erreicht werden. Typ-Prädikate sind in diesem Fall in einer statisch typisierten Programmiersprachen nicht notwendig. Zwei verschiedene Repräsentationsformen und eine Funktion, die beide Repräsentationen gleichermaßen verwenden kann, sind hier aufgeführt.

// ADT = Algebraischer Datentyp
type ADTPunkt = ADTPunkt of int * int with
    member this.X = let(ADTPunkt(x,_)) = this in x
    member this.Y = let(ADTPunkt(_,y)) = this in y

type DatensatzPunkt = { X: int; Y: int }

// Beispiel-Funktion length: ^a -> int * int
// when ^a : (member get_X : ^a -> int)
//  and ^a : (member get_Y : ^a -> int)
let inline length(Punkt(x, y)) =
  sqrt(float(x * x + y * y))

// Verwendung
printfn "%d" (length { X = 1; Y = 1 }) // gibt 1.414214 aus
printfn "%d" (length(ADTPunkt(1, 1)))  // ebenso

Subtyp-Polymorphie

Die intuitive Herangehensweise bei objektorientierter Programmierung ist Subtyp-Polymorphie, die sich wie in Abbildung # darstellen lässt und im Polymorphie-Abschnitt im Anhang zu finden ist. Wie im Diagramm dargestellt wird eine Oberklasse erstellt, die zwei Operationen enthält: Evaluate und Apply, die beide Standard-Implementierungen besitzen (hier: keine weitere Evaluation und keine Applizierbarkeit). In Unterklassen werden Methoden implementiert, um dieses Verhalten für konkrete Fälle umzusetzen, wie etwa Variablen, die nachgeschlagen werden.


subtyp
Auschnitt der Klassenhierarchie für Ausdrücke einer simplen Programmiersprache.

Philip Wadlers expression problem

Ein wichtiger Aspekt bei dieser Diskussion ist Erweiterbarkeit, sowohl um neue Fälle (Varianten) und Operationen (Funktionen). Eine 1998 entstandene Bezeichnung für diesen Sachverhalt ist Philip Wadlers expression problem:

The Expression Problem is a new name for an old problem. The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts). For the concrete example, we take expressions as the data type, begin with one case (constants) and one function (evaluators), then add one more construct (plus) and one more function (conversion to a string). [ExpressionProblem]

Eine Auflistung von bisherigen Lösungsansätzen und ein eigener Ansatz wird in [Scala] präsentiert. In den abschließenden Betrachtungen gehe ich auf diesen Aspekt ein und stelle den Bezug der Techniken auf diese Forderungen grafisch dar.

Imperative Ansätze

Die imperativen Ansätze, switch über Type Code bzw. if-then-else mit Typtests und -casts, orientieren sich an der Funktionsweise von Pattern matching, verwenden jedoch explizite Typecast und Typprüfungen. Auf diese Weise können Funktionen unabhängig von den Varianten definiert werden. Neue Varianten dürfen nicht hinzugefügt werden, weil bestehende Operationen neue Fälle nicht behandeln können. Bei algebraischen Datentypen ist dies per Definition ausgeschlossen, für objektorientierte Sprachen wurde dies im Teil über Varianten im Abschnitt über imperativ-objektorientierte Typen gezeigt.

Im Beispiel nimmt die Evaluate-Methode des Evaluators diese Unterscheidung direkt vor. Die Fallunterscheidung (ob mit if-then-else oder mit switch) als Programmierer selbst vorzunehmen, führt zu Boilerplate-Code und zu einem schwer um neue Fälle erweiterbaren Entwurf.

public Code Evaluate(Dictionary<string, Code> env, Code expr) {
  Var variable = expr as Var;
  if(variable != null) {
      return env[variable.Name];
  }
  ...
}

Try-Methoden werden in dieser Darstellung nicht weiter betrachtet, weil ihr Einsatz in diesem Beispiel wenig Gewinn im Vergleich zum Typtest und Typecast bringt. Beispielsweise ist für die Variante Var Folgendes vorstellbar, benötigt aber die Methode bool TryVar(out string name) in der Basisklasse, die dort false zurückgibt und nur in der Klasse Var das Feld an den Out-Parameter bindet und true zurückgibt.

public Code Evaluate(Dictionary<string, Code> env, Code expr) {
  string name;
  if(expr.TryVar(out name)) {
      return env[name];
  }
  ...
}

Das Besucher-Entwurfsmuster (Visitor pattern)

Beim Besucher-Entwurfsmuster geht es um eine einfache Typunterscheidung, sodass die eben genannte Typ-Unterscheidung nicht mit Typtests und Typecasts durchgeführt werden muss. Die oben genannte Voraussetzung bleibt bestehen, dass die Hinzunahme neuer Fälle alte Operationen ungültig macht.

Ein Nachteil ist relativ viel Boilerplate-Code, der in jeder Unterklasse eingefügt werden muss. Das Visitor-Interface muss Kenntnis über alle Varianten besitzen.

Ein viel gravierender Nachteil ist, dass das Besucher-Entwurfsmuster im Gegensatz zum Pattern matching nur eine einfache Typ-Unterscheidung vornimmt und mit geschachtelten Unterscheidungen nicht umgehen kann. Dies wird im Fall des Evaluator-Beispiels dadurch deutlich, dass bei einer Applikation geprüft wird, was appliziert werden soll. Im Code für den Visitor-Ansatz wird dies mit einer zweiten Visitor-Klasse gelöst, die dann diese Entscheidung vornimmt. Speicherung von Zusatzinformationen, unter anderem die Argumente der Applikation und die Variablenbindungen, werden zur Aufgabe des Programmierers; im Pattern-matching- und imperativen Evaluator hingegen befanden sich diese Werte im Variablen-Sichtbereich und standen somit zur Verfügung. Im Fall von Subtyp-Polymorphie wurden die Argumente der Applikation als Parameter übergeben.

Abschließende Betrachtung

Diese Untersuchung hat einen Teil der Möglichkeiten der Fallunterscheidungen dar- und gegenübergestellt. Ein wichtiger Aspekt bei dieser Diskussion ist das Expression Problem und die Frage, wieweit Fälle und Operationen hinzugefügt werden können. Damit im Zusammenhang steht das Open Closed Principle, das besagt, das objektorientierte Klassen offen für Erweiterungen (vor allem Fälle) und geschlossen gegenüber Änderungen sein sollen (Quelltext von Basisklassen soll nicht neukompiliert werden müssen). Gerade durch diese Anforderung an Klassen wird die Notwendigkeit der Kompositionierbarkeit und Modularität deutlich, die Mixins bzw. Traits bieten. Diese Techniken gibt es in beispielsweise in Scala und werden für den Lösungsansatz in [Scala] exzessiv verwendet.

Auf der anderen Seite sind deklarative Fallunterscheidungen mit Pattern matching intuitiv zu formulieren, berufen sich aber auf eine abgeschlossene Variantenanzahl. Active Patterns können mit Klassifizierern eine Varianten-ähnliche Sicht z.B. auf eine Klassenhierarchie bieten. Dies wurde in [ActivePattern, S. 42] im Fall vom Typ Type (der einen Typen darstellt) als Beispiel angeführt.

Im Beispiel habe ich für den Evaluator definiert, dass die einzige Erweiterung durch eingebaute Funktionen (BuiltInFuncs) stattfinden darf. Im Falle, dass neue Operationen auf diesen Datentypen hinzugefügt werden soll, etwa eine Übersetzung des Ausdrucks in einen Scheme-Ausdruck (z.B. in Form eines Strings), lässt sich dies ebenfalls als Funktion umsetzen, die Pattern matching verwendet.

Das Beispiel hat durchaus Praxisrelevanz, nicht nur auf konzeptioneller Ebene, weil Syntaxbäume für Metaprogrammierung sinnvoll sind, sondern weil die konkreten Basisbibliotheken von C# und F# diese Typen verwenden. In F# sind dies die schon genannten Quotations, die ausführlicher in [FSharp, S. 498] diskutiert werden und in C# ist dies die Klassenhierarchie der LINQ-Expressions (Details finden sich in [CSharp, S. 377ff.]).

Die Verwendung der Typen ist bei F#-Quotations mit Pattern matching und Active Patterns konzipiertVerschiedene Active Patterns sind unter Microsoft.FSharp.Quotations zu finden. und bei C#-LINQ-Expressions ist die Visitor-Basisklasse System.Linq.Expression.ExpressionVisitor zu verwenden.

Eine andere Überlegung stammt aus der dynamisch typisierten objektorientierten Programmiersprache Smalltalk und geht davon aus, dass der Quelltext von Basisklassen (z.B. die Smalltalk-Klassen Object oder String) offenliegt und während der Anwendungsprogrammierung verändert werden darf. So lassen sich neue (abstrakte) Operationen in der Basisklasse einfügen und in Unterklassen überschreiben (bzw. implementieren). In der ebenfalls dynamisch typisierten objektorientierten Programmiersprache Ruby ist dies auch vorgesehen und beruft sich auf Metaprogrammierungstechniken wie eval (Ausführen eines Strings als Programmcode), class_eval zur Änderung von Klassen und define_method zum Hinzufügen von Methoden.


expressionproblem
Techniken und ihre Einordnung nach den Kriterien Erweiterbarkeit um neue Fälle (Varianten) und Operationen (Funktionen).

6 Fazit

Dargestellte Aspekte

Gesamtbild deklarativ: Nach einer Defintionsgegenüberstellung habe ich eine eigene Definition gegeben, um unter anderem funktionale Programmiersprachen mit Seiteneffekten als Vertreter einzuordnen und deklarative Techniken (Regeln: Pattern matching und Active Patterns, Zusammenhänge: Computation Expression) zu untersuchen, die auf hoher Abstraktionsebene arbeiten, ohne dass Details immer wieder ausprogrammiert werden müssen. Im Fall von Active Patterns und Computation Expressions müssen diese Details einmal programmiert werden und lassen sich wiederverwenden.
Historische Heranführung: Prolog und Miranda haben eine überschaubare Syntax, basieren auf wenigen Konzepten und können damit bereits viele Probleme elegant lösen. Referenzielle Transparenz ist eine nützliche Eigenschaft für das Programm-Verstehen und die Parallelisierung. Multiparadigmatische Programmiersprachen sind komplexer und umfangreicher, dafür aber mächtiger und flexibler, da Zugriff auf mehrere Herangehensweisen (deklarative und imperative) gewährt wird. Das Abwägen, welche sich anbieten war Inhalt dieser Arbeit.
Deklarative Typ-Definitionen: In F# lassen sich Datensätze und algebraische Datentypen einfach definieren. Mit wenig Schreibaufwand werden komplexe Typen und Klassenhierarchien definiert.
Wert-Verarbeitung (Pattern matching): Deklarativ definierte Typen können mit Pattern matching intuitiv verarbeitet werden.
DSLs und Metaprogrammierung: Wenn die Sprache um neue Konstrukte erweitert werden soll, kann dies mit Metaprogrammierung getan werden. Interne DSLs stellen eine Fokussierung der Programmiersprache auf ein Problemfeld dar. Die Umsetzung der somit formulierten Sprache muss nicht an die Standardauswertungsumgebung gebunden sein, sondern kann eine andere sein.

Passende imperative Techniken und Herangehensweisen wurden dargestellt und Zusammenhänge zur deklarativen Programmierung gezeigt:

Veränderlichkeit / Konsistenzprüfung: Konsistenz-Prüfungen dienen einem sicheren Umgang mit Seiteneffekten und null-Werten.
Typ-Defintionen und -Belange: Viele Aufgaben sind bei Typ-Definition zu erledigen, um verwendbare Typen zu programmieren: Gleichheit, Initialisierung, Kopieren, Persistierung, Verwendung in Klassenhierarchien.
Fallunterscheidungen: Behandelt wurden if-then-else und switch auf der reinen imperativen Seite und Subtyp-Polymorphie und das Entwurfsmuster Besucher auf der objektorientierten Seite. Auf Fallunterscheidungstechniken bin ich besonders eingegangen, weil sie den Regel-Begriff aus meiner Definition darstellen. Die Darstellung gegenüber Pattern matching wurde in der Evaluation gezeigt. In diesem Sinne habe ich Bezug auf das Expression Problem genommen und die zwei Dimensionen der Erweiterbarkeit für die Lösungen dargestellt.

Ausgelassene Aspekte

Scala: Scala ist umfangreich, sowohl die Anzahl der Konzepte als auch die Basis-Bibliothek. Außerdem gibt es in Scala neue Konzepte, die es vorher in der objekt-funktionalen Form noch nicht gegeben hat. Ein Beispiel sind Module als first class values, die bei der Keynote der Scala-Konferenz flatMap in Oslo (13. – 14.05.2013) vorgestellt wurdenhttp://2013.flatmap.no/spiewak.html. Zudem habe ich nicht genügend Praxiserfahrung mit Scala.
Weitere Entwurfsmuster und funktionale Konzepte: Entwurfsmuster kann man als objektorientiertes Handwerkszeug ansehen: Man muss Entwurfsmuster verstehen, um mit objektorientierten Programmbibliotheken arbeiten zu können und auf der anderen Seite Entwurfsmuster in eigenen Bibliotheken verwenden, damit andere objektorientierte Programmierer diese wiederverwenden können.

In [AnalyseEntwurfsmusterFP] wird ein Vergleich von Entwurfsmustern mit funktionalen Konzepten umfangreich dargestellt, deshalb bin ich bin in dieser Arbeit nicht auf weitere Entwurfsmuster eingegangen.

Eine gute Einführung in funktionale Programmierung, in der verzögerte Auswertung (Laziness) und Funktionen höherer Ordnung als Eckpfeiler für modulare Programmierung vorgestellt werden, ist [WhyFPMatters]. Funktionen höherer Ordnung gehören zum Handwerkszeug des funktionalen Programmierers und wurden in dieser Arbeit wie selbstverständlich verwendet. In moderneren objektorientierten Programmiersprachen halten sie zusammen mit Lambda-Ausdrücken als Features Einzug.

Expression Problem: Bei der Evaluation der Fallunterscheidungstechniken gibt es nicht nur den Aspekt der Eleganz sondern auch die Frage um Erweiterbarkeit mit Funktionen und Fällen. Bei dem oben genannten Vortrag wird das Problem aufgegriffen und es wird eine Lösung aus der dynamisch typisierten funktionalen Programmiersprache Clojure (einem LISP-Ableger von 2007) vorgestellt, die auf extern definierten Funktionen wie in CLOS basiert. Eine statisch typisierte Lösung ist in [Scala] zu finden.
Objektorientierte Sicht: Ich habe mich für F# und nicht C# entschieden, weil ich nicht den Weg von der Objektorientierung zur funktionalen Programmierung einschlage, sondern im deklarativ-funktionalen Programmiersprachenraum anfange, Konzepte zu untersuchen. Ein sehr gutes Buch, das C#-Programmierer die funktionale Denkweise (mit C# und F#) anschaulich vermittelt, ist [RealWorldFP].
Formale Programmiersprachen-Untersuchung: Formale Untersuchungen über funktionale Programmiersprachen sind aufgrund des mathematischen Anspruchs, den diese Programmiersprachen haben, sinnvoll. Dasselbe gilt für Untersuchungen im Bereich der Logik zur Logik-Programmierung. In diesem Zusammenhang werden deklarative Programmiersprachen gerne Akademikersprachen genannt, die sich eher nicht für typische Anwendungsprogrammierung eignen und nur im universitären Umfeld genutzt werden. Dies wird durch Konzepte wie Monaden und Typklassen aus Haskell verschärft, die Akademiker benutzen, für durchschnittliche Programmierer hingegen kompliziert zu verwenden sind. Haskell steht somit anderen gängigeren Programmiersprachen in der Akzeptanz nach.

In diesem Sinne halte ich eine formale Betrachtungsweise von F# im Zuge dieser Bachelorarbeit nicht für sinnvoll.

Schlusswort

Deklarative Programmierung wurde in dieser Arbeit als Kombination von moderner funktionaler Programmierung und der Verwendung von DSLs vorgestellt. Insbesondere Programmiersprachen wie F# und Scala bringen diese beiden Aspekte in die Welt der Anwendungsprogrammierung, sodass Probleme mithilfe von funktionaler Programmierung und objektorientierten Programmbibliotheken gelöst werden können, was insbesondere in Bezug auf das Programmieren von grafischen Benutzeroberflächen und Datenbanken nützlich ist. Um den in einigen Situationen geforderten schnellen wahlfreien Zugriff auf große Datenmengen zu gewährleisten, kann auf das imperative Array zurückgegriffen werden.

Nicht nur die deklarative Seite wurde beleuchtet, auch Teile der imperativen Programmierung wurden angeschnitten, wobei die imperative Welt viel umfangreicher ist, als ich in dieser Bachelorarbeit behandeln könnte. Die deklarative Seite von F# hingegen wurde zu großen Teilen vorgestellt, weil sie auf überschaubar wenigen Konzepten basiert (z.B. Pattern matching und einfach zu verwendende Typen). Das mag auch der Grund sein, warum einige deklarative Sprachen wie Prolog oder Scheme in kürzerer Zeit gelehrt werden können als imperative-objektorientierte Programmierung, die umfangreich und komplex ist. Damit soll durchaus nicht relativiert werden, dass auch funktionale und Logik-Programmierung ein weites Feld sind.

Diese Arbeit lässt sich als Kompendium für deklarative Programmierung mit F# verwenden, wobei Pattern matching und Typen eine zentrale Rolle spielen.

7 Literatur- und Quellenverzeichnis

  • [ActivePattern]
    Don Syme, Gregory Neverov, James Margetson: Extensible Pattern Matching via a Lightweight Language Extension. ICFP ’07 Proceedings of the 12th ACM SIGPLAN international conference on Functional programming (S. 29-40). ACM Press. 2007.
  • [AnalyseEntwurfsmusterFP]
    Johannes Pietrzyk: Analyse der Entwurfsmuster der Viererbande unter dem Funktionalen Paradigma. Bachelorarbeit am Fachbereich Informatik an der Universität Hamburg. 2012.
  • [CSharp]
    Joseph Albahari, Ben Albahari: C# 5.0 in a Nutshell. 5te Auflage. O’Reilly. 2012.
  • [Cormen]
    Thomas H. Cormen, Charles Leiserson, Ronald L. Rivest, Clifford Stein: Algorithmen – Eine Einführung. 3te Auflage. Oldenbourg Verlag. 2010.
  • [Curry]
    Michael Hanus: Teaching Functional and Logic Programming with a Single Computation Model. Programming Languages: Implementations, Logics, and Programs (S. 335-350). Springer Berlin Heidelberg. 1997.
  • [DeklarativeProgrammierung]
    Marc H. Scholl: Deklarative Programmierung. Vorlesungsskript an der Universität Konstanz. 2006. URL: http://www.inf.uni-konstanz.de/dbis/teaching/ss06/fp/fp.pdf (abgerufen am 24.07.2013)
  • [DSLs]
    Martin Fowler, Rebecca Parsons: Domain-specific languages. Addison-Wesley. 2011.
  • [EffectiveJava]
    Joshua Block: Effective Java. 2te Auflage. Addison-Wesley. 2008.
  • [Entwurfsmuster]
    Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Entwurfsmuster – Elemente für wiederverwendbare Software. 6te Auflage. Addison-Wesley. 2010.
  • [ExpressionProblem]
    E-Mail-Diskussion, E-Mail von Philip Wadler (wadler@research.bell-labs.com): The Expression Problem. 1998. URL: http://www.daimi.au.dk/~madst/tool/papers/expression.txt (abgerufen am 27.07.2013).
  • [FPWithMiranda]
    Ian Holyer: Functional Programming with Miranda. University College London (ULC) Press. 1993.
  • [FSharp]
    Don Syme, Adam Granicz, Antonio Cisternino: Expert F# 3.0. 3te Auflage. Apress. 2012.
  • [FSharpMeta]
    Don Syme: Leveraging .NET Meta-programming Components from F# – Integrated Queries and Interoperable Heterogeneous Execution. Proceedings of the 2006 workshop on ML. ACM New York. 2006. URL: http://research.microsoft.com/apps/pubs/default.aspx?id=147193 (abgerufen am 28.07.2013).
  • [FSharpSpec]
    Don Syme: The F# 3.0 Language Specification. 2012. URL: http://fsharp.org/about/files/spec.pdf (abgerufen am 21.07.2013).
  • [FunctionalArrays]
    Melissa E. O’Neil, F. Warren Burton: A New Method for Functional Arrays. Journal of Functional Programming archive Volume 7 Issue 5, September 1997 (S. 487-513). Cambridge University Press. 1997.
  • [FunktProg]
    Peter Pepper, Petra Hofstedt: Funktionale Programmierung: Sprachdesign und Programmiertechnik. eXamen.press, Springer-Verlag. 2006.
  • [InformatikLexikon]
    Peter Fischer, Peter Hofer: Lexikon der Informatik. 14te Auflage. Springer. 2007.
  • [LanguageOrientedProg]
    Martin P. Ward: Language Oriented Programming. Software—Concepts and Tools 1995. Band 15. S. 147-161. 1995.
  • [MetaprogDotNet]
    Kevin Hazzard, Jason Bock: Metaprogramming in .NET. Manning. 2013.
  • [MultiparadigmenProg]
    Martin Grabmüller: Multiparadigmen-Programmiersprachen. 2003-15 in Forschungsberichte Fakultät IV – Elektrotechnik und Informatik. Technische Universität Berlin. 2003.
  • [PractAdvantDecl]
    John W. Lloyd: Practical Advantages of Declarative Programming.
    Joint Conference on Declarative Programming, GULP-PRODE. 1994.
  • [RealWorldFP]
    Thomas Petricek, John Skeet: Real-world functional programming: with examples in F# and C#. Manning. 2010.
  • [Scala]
    Martin Odersky and Matthias Zenger: Independently Extensible Solutions to the Expression Problem. EPFL Technical Report IC/2004/33. École Polytechnique Fédérale de Lausanne, Switzerland. 2004. URL: http://lampwww.epfl.ch/~odersky/papers/ExpressionProblem.html (abgerufen am 27.07.2013).
  • [SICP]
    Hal Abelson, Jerry Sussman, Julie Sussman: Structure and Interpretation of Computer Programs. MIT Press. 1984. URL: http://sicpebook.wordpress.com/2011/05/28/new-electronic-sicp (abgerufen am 21.07.2013).
  • [WhyFPMatters]
    David Turner: Why Functional Programming Matters. Research Topics in Functional Programming, ed. D. Turner (S. 17–42). Addison-Wesley. 1990.

8 Anhang

Listing 1: Miss Grant’s Controller in F#

type condition = DoorClosed | DrawerOpened | LightOn
               | DoorOpened | PanelClosed
and actions = UnlockPanel | LockPanel | LockDoor | UnlockDoor
and codes = D1CL | D2OP | L1ON | D1OP | PNCL
          | PNUL | PNLK | D1LK | D1UL
and stateName = Idle | Active | WaitingForLight
              | WaitingForDrawer | UnlockedPanel
and state = {
    name: stateName;
    actions: actions list;
    transitions: (condition * stateName) list
}
and machine = {
    events : (condition * codes) list
    resetEvents: condition list
    commands : (actions * codes) list
    states : state list
}
 
let inline (=>) a b = (a, b)
let inline (:=) name (actions, transitions) =
    { name = name; actions = actions; transitions = transitions }
 
let machine = {
    events = [
                DoorClosed => D1CL
                DrawerOpened => D2OP
                LightOn => L1ON
                DoorOpened => D1OP
                PanelClosed => PNCL
    ];
    resetEvents = [ DoorOpened ];
    commands = [
                UnlockPanel => PNUL
                LockPanel => PNLK
                LockDoor => D1LK
                UnlockDoor => D1UL
    ];
     states = [
                Idle := [UnlockDoor; LockPanel]
                  => [DoorClosed => Active]
                Active := []
                  => [DrawerOpened => WaitingForLight;
                      LightOn => WaitingForDrawer]
                WaitingForLight := []
                  => [LightOn => UnlockedPanel]
                WaitingForDrawer := []
                  => [DrawerOpened => UnlockedPanel]
                UnlockedPanel := [UnlockPanel; LockDoor]
                  => [PanelClosed => Idle]
        ]
}

open System
open System.Text.RegularExpressions
open Microsoft.FSharp.Reflection
let run { events = events; resetEvents = resetEvents;
          commands = commands; states = states } =
    let assoc key (k, value) = if k = key then Some value else None
    let listAssoc key = List.pick(assoc key)
    let codeForEvent cond =
      events |> listAssoc cond
    let codeForAction action =
      commands |> listAssoc action
    let start = states.Head
    let splitOnCamelCase(word: string) = 
        String.concat "" [
            for i in 1..word.Length-1 do
                let a, b = word.[i-1], word.[i]
                yield string a
                if Char.IsLower a && Char.IsUpper b then yield " "
            yield string word.[word.Length-1]
        ]
    let print x = splitOnCamelCase(sprintf "%A" x)
    let printList select list =
      String.concat ", "
       (Seq.map (fun x -> print (select x)) list)
    let cases =
        let ctor = FSharpValue.PreComputeUnionConstructor
        FSharpType.GetUnionCases(typeof<condition>)
        |> Array.map(fun x -> (x.Name.ToUpper(),
                               ctor x [||]:?> condition))
    let readCondition() =
        let input = Console.ReadLine().Replace(" ", "").ToUpper()
        cases |> Array.tryPick(assoc input)
    let rec repl(state: state)(input: condition) =
        printfn "Received %s (%s)..."
            (print input) (print(codeForEvent input))
        match List.tryPick(assoc input) state.transitions with
        | Some next ->
            state.actions |> List.iter(fun x ->
                printfn "Doing %s (%s)..."
                    (print x) (print(codeForAction x)))
            states |> List.find(fun x -> x.name = next) |> startRepl
        | None ->
            if resetEvents |> List.exists((=)input) then
                startRepl start
            else
                startRepl state
    and startRepl state = 
        printfn "You're now in state %s." (print state.name)
        printfn "Transitions: %s" (printList fst state.transitions)
        let rec findSome() =
            printf "> "
            match readCondition() with
            | Some cond -> repl state cond
            | None ->  findSome()
        findSome()
    printfn "Reset transitions: %s" (printList id resetEvents)
    startRepl start

[<EntryPoint>]
let main _ = run machine

// Beispiel:
// Reset transitions: Door Opened
// You're now in state Idle.
// Transitions: Door Closed
// > Door Closed
// Received Door Closed (D1CL)...
// Doing Unlock Door (D1UL)...
// Doing Lock Panel (PNLK)...
// You're now in state Active.
// Transitions: Drawer Opened, Light On
// > Light On
// Received Light On (L1ON)...
// You're now in state Waiting For Drawer.
// Transitions: Drawer Opened
// > Drawer Opened
// Received Drawer Opened (D2OP)...
// You're now in state Unlocked Panel.
// Transitions: Panel Closed
// > Panel Closed
// Received Panel Closed (PNCL)...
// Doing Unlock Panel (PNUL)...
// Doing Lock Door (D1LK)...
// You're now in state Idle.
// Transitions: Door Closed
// > _

Listing 2: XML-Traversierung mit Active Patterns in F#

#r "System.Xml.Linq"
open System.Xml.Linq
 
let (|Node|_|)(name: string)(xObj: XObject) =
    match xObj with
    | :? XElement as element
        when element.Name.LocalName = name ->
    Some(element.Nodes())
    | _ -> None
     
let (|Text|_|)(xObj: XObject) =
    match xObj with
    | :? XElement -> None
    | _ -> Some(xObj.ToString())
 
let (|Attribute|_|)(name: string)(xObj: XObject) =
    match xObj with
    | :? XElement as element ->
        match element.Attribute(XName.Get(name)) with
        | null -> None
        | x -> Some(x.Value)
    | _ -> None
 
let rec traverseAll = Seq.iter traverseNode
and traverseNode = function
| Text text -> printfn "    %s" (text.Trim())
| Node "Matches" children -> traverseAll children
| Node "Match" children & Attribute "Winner" winner
  & Attribute "Loser" loser & Attribute"Score" score ->
    printfn "%s won against %s with score %s" winner loser score
    traverseAll children

let sampleXml = @"<Matches>
  <Match Winner='A' Loser='B' Score='1:0'>
    Description of the first match...
  </Match>
  <Match Winner='A' Loser='C' Score='1:0'>
    Description of the second match...
  </Match>
</Matches>"

traverseNode(XElement.Parse(sampleXml))

Listing 3: Generische Variante von Counting Sort in F#

> let inline SortInPlaceGeneric numbers =
    let maximum = Array.max numbers
    let occurences = Array.zeroCreate(int maximum + 1)
    for num in numbers do
        occurences.[int num] <- occurences.[int num] + 1
    let mutable insertionIndex = 0
    let mutable num = LanguagePrimitives.GenericZero
    while num <= maximum do
        for times = 1 to occurences.[int num] do
            numbers.[insertionIndex] <- num
            insertionIndex <- insertionIndex + 1
        num <- num + LanguagePrimitives.GenericOne
    numbers;;

val inline SortInPlaceGeneric : ^a [] ->  ^a []
  when  ^a : (static member get_Zero : ->  ^a)
   and  ^a : (static member op_Explicit :  ^a -> int) 
   and  ^a : comparison 
   and (^a or  ^b) : (static member ( + ) :  ^a *  ^b ->  ^a) 
   and  ^b : (static member get_One : ->  ^b)

// Beispielnutzung mit Ganzzahltypen int, int64, sbyte (signed byte), byte, int16 (suffix s für short), BigInteger
> SortInPlaceGeneric [| 1; 2; 3; 14; 120; 0; 2; 4 |];;
val it : int [] = [|0; 1; 2; 2; 3; 4; 14; 120|]
> SortInPlaceGeneric [| 1L; 2L; 3L; 14L; 120L; 0L; 2L; 4L |];;
val it : int64 [] = [|0L; 1L; 2L; 2L; 3L; 4L; 14L; 120L|]
> SortInPlaceGeneric [| 1y; 2y; 3y; 14y; 120y; 0y; 2y; 4y |];;
val it : sbyte [] = [|0y; 1y; 2y; 2y; 3y; 4y; 14y; 120y|]
> SortInPlaceGeneric [| 1uy; 2uy; 3uy; 14uy; 120uy; 0uy; 2uy; 4uy |];;
val it : byte [] = [|0uy; 1uy; 2uy; 2uy; 3uy; 4uy; 14uy; 120uy|]
> SortInPlaceGeneric [| 1s; 2s; 3s; 14s; 120s; 0s; 2s; 4s |];;
val it : int16 [] = [|0s; 1s; 2s; 2s; 3s; 4s; 14s; 120s|]
> SortInPlaceGeneric [| 1I; 2I; 3I; 14I; 120I; 0I; 2I; 4I |];;
val it : System.Numerics.BigInteger [] =
   [|0I; 1I; 2I; 2I; 3I; 4I; 14I; 120I|]

Listing 4: Prolog-ähnliche Quotation in F#

> open Microsoft.FSharp.Core.Operators.Unchecked
  let predicate<'a> = ignore<'a> // ignoriert den Parameter (f x = ())
  let value<'a> = defaultof<'a> // liefert null/false/0/0.0, je nach Typ
  // ^- Für das Typsystem, die Funktionen sollen nicht ausgeführt werden.
  let prolog x = x // Hier käme die Metaprogrammierung
                   // (Verarbeitung der Quotation x)

  let memb<'a> = predicate<'a * 'a list>
  let E<'a> = value<'a>
  let __<'a> = value<'a>
  let R<'a> = value<'a list>
  let (<--) a b = ();;
...
> prolog <@
          memb(E, E :: __)
          memb(E, __ :: R) <-- memb(E, R)
  @>;;
val it : Quotations.Expr<unit> =
    Sequential (Application (Call (None, memb, []),
                        NewTuple (Call (None, E, []),
                              NewUnionCase (Cons, Call (None, E, []),
                                Call (None, __, [])))),
      Call (None, op_LessMinusMinus,
      [Application (Call (None, memb, []),
        NewTuple (Call (None, E, []),
            NewUnionCase (Cons,
              Call (None, __, []),
              Call (None, R, [])))),
       Application (Call (None, memb, []),
        NewTuple (Call (None, E, []), Call (None, R, [])))]))

8.1 Anhang zum Beispiel Evaluator

Listing 5: Evaluator – algebraische Datentypen / Pattern matching

/// Stellt einen Ausdruck oder ein Ergebnis einer simplen Programmiersprache dar.
type Code =
/// Number(Konstante Ganzzahl)
| Number of int
/// Bool(Konstanter Wahrheitswert)
| Bool of bool
/// Var(Name)
| Var of string
/// Binding(Name, Wert, Ausdruck)
| Binding of string * Code * Code
/// Conditional(Bedingung, Folge, Alternative)
| Conditional of Code * Code * Code
/// Application(Funktion, Argument-Liste)
| Application of Code * Code list
/// Lambda(Parameter-Namen, Ausdruck)
| Lambda of string list * Code
/// Closure = Lambda + Variablenbindungen
| Closure of Map<string, Code> * string list * Code
/// BuiltInFunc(F#-Funktion) (die Funktion erhält ausgewertete Argumente)
| BuiltInFunc of (Code list -> Code)

module Evaluator =
    let rec eval env expr =
        match expr with
        | Number _ | Bool _ | BuiltInFunc _ | Closure _ -> expr
        | Lambda(param, body) -> Closure(env, param, body)
        | Var name -> Map.find name env
        | Binding(name, value, body) ->
            eval (Map.add name (eval env value) env) body
        | Conditional(condition, thenExpr, elseExpr) ->
            match eval env condition with
            | Bool false -> eval env elseExpr
            | _ -> eval env thenExpr
        | Application(func, args) ->
            match eval env func with
            | Closure(extendedEnv, names, body) ->
                let addToMap map (key, value) = Map.add key value map
                let newEnv = List.fold addToMap extendedEnv (List.zip names (List.map (eval env) args))
                eval newEnv body
            | BuiltInFunc(func) ->
                func (List.map (eval env) args)
            | other -> failwithf "Only closures and built-in functions can be applied, found: %A" other
        
    let Evaluate(expr) = eval Map.empty expr

module BuiltInFuncs =
    let toNumber = function
        | Number value -> value
        | other -> failwithf "Integer expected, found: %A" other

    let equality = function
        | Number value1, Number value2 -> value1 = value2
        | Bool value1, Bool value2 -> value1 = value2
        | _ -> false

    let plus() = BuiltInFunc(fun args ->
        Number(List.sumBy toNumber args))

    // let (|>) x f = f(x) // Pipelining [FSharp, vgl. S. 40-41]
    let times() = BuiltInFunc(fun args ->
        args |> List.map toNumber |> List.fold (*) 1 |> Number)

    // geschachtelte Schreibweise ohne (|>)
    let times'() = BuiltInFunc(fun args ->
        Number(List.fold (*) 1 (List.map toNumber args)))

    let eq() = BuiltInFunc(fun args ->
        args |> Seq.pairwise |> Seq.forall equality |> Bool)

    let lt() = BuiltInFunc(fun args ->
        args |> Seq.map toNumber |> Seq.pairwise
                  |> Seq.forall(fun(a, b) -> a < b) |> Bool)

open Evaluator
open BuiltInFuncs

#if INTERACTIVE
#I "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\PublicAssemblies"
#r "Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll"
#endif
open Microsoft.VisualStudio.TestTools.UnitTesting
open System
open System.Reflection
[<TestClass>]
type FunctionalTests() =
    let (-->) expr result =
        let raw = function
        | Number x -> box x
        | Bool b -> box b
        | _ -> obj()
        let evaluated = Evaluate(expr)
        Assert.AreEqual(raw evaluated, raw result,
                        sprintf "expected %A <> actual %A (expr: %A)"
                                result evaluated expr)

    static member RunInConsole() =
        let tester = FunctionalTests()
        let tests =
            typeof<FunctionalTests>.GetMethods()
            |> Array.filter(fun test ->
                        Attribute.IsDefined(test, typeof<TestMethodAttribute>))
        let mutable passed = 0
        for test in tests do
            try
                test.Invoke(tester, null) |> ignore
                passed<- passed + 1
                printfn "OK: %s" test.Name
            with :? TargetInvocationException as e ->
                try raise(e.InnerException)
                with :? AssertFailedException as e ->
                    printfn "%s\n%s\n"
                        test.Name (e.Message.Replace(". ", "\n"))
        printfn "\n%d von %d Tests bestanden." passed tests.Length
                    
    [<TestMethod>]
    member this.FunctionalLet() =
        let sample = // (let ([x 20]) (+ x x 4))
            Binding("x", Number 20,
              Application(plus(), [Var "x"; Var "x"; Number 4]))
    
        sample --> Number 44

    [<TestMethod>]
    member this.FunctionalSquare() =    
        let square = // (lambda (x) (* x x))
            Lambda(["x"], Application(times(), [Var "x"; Var "x"]))

        for i = -100 to 100 do
            Application(square, [Number i]) --> Number(i * i)
            
    [<TestMethod>]
    member this.FunctionalMinimum() =    
        let minimum = // (lambda (a b) (if (< a b) a b))
            Lambda(["a"; "b"],
                Conditional(Application(lt(), [Var "a"; Var "b"]),
                    Var "a", Var "b"))

        for i = -10 to 10 do
            for k = -10 to 10 do
                Application(minimum, [Number i; Number k]) --> Number(min i k)
                
    [<TestMethod>]
    member this.FunctionalFactorial() =
    // "Rekursiver" Lambda-Ausdruck:
    // (lambda (cont x) (if (= x 0) 1 (* x (cont cont (- x 1)))))
        let factorial = 
            Lambda(["cont"; "x"],
                Conditional(
                    Application(eq(), [Var "x"; Number 0]),
                    Number 1,
                    Application(times(),
                        [Var "x"; Application(Var "cont",
                                         [Var "cont"; Application(plus(),
                                                    [Var "x"; Number -1])])])))
        for i = 0 to 10 do
            Application(factorial, [factorial; Number i])
                --> Number(Seq.fold (*) 1 { 1..i })

    [<TestMethod>]
    member this.FunctionalClosure() =
        let cons = // (lambda (hd tl) (lambda (takeHead) (if takeHead hd tl)))
            Lambda(["hd"; "tl"],
                Lambda(["takeHead"], 
                    Conditional(
                        Var "takeHead",
                        Var "hd",
                        Var "tl")))

        let empty = Bool false // #f

        let head = // (lambda (consCell) (consCell true))
            Lambda(["xs"], Application(Var "xs", [Bool true]))

        let tail = // (lambda (consCell) (consCell false))
            Lambda(["xs"], Application(Var "xs", [Bool false]))

        let isEmpty = // (lambda (consCell) (if consCell #f #t))
            Lambda(["xs"], Conditional(Var "xs", Bool false, Bool true))


        let oneTwo = // (cons 1 (cons 2 empty))
            Application(cons, [Number 1;
                Application(cons, [Number 2; empty])])

        Application(head, [oneTwo]) --> Number 1
        Application(head, [Application(tail, [oneTwo])]) --> Number 2
        Application(tail, [Application(tail, [oneTwo])]) --> empty

        Application(isEmpty, [empty]) --> Bool true
        Application(isEmpty, [oneTwo]) --> Bool false
        Application(isEmpty, [Application(tail, [oneTwo])])
          --> Bool false
        Application(isEmpty, [Application(tail, [Application(tail, [oneTwo])])])
          --> Bool true

#if INTERACTIVE
FunctionalTests.RunInConsole()
#endif

Listing 6: Evaluator – datenorientiert mit Typtests

using System;
using System.Collections.Generic;

namespace Typtests
{
    abstract public class Code { }
    public class Number : Code { public int Value; }
    public class Bool : Code { public bool Value; }
    public class Var : Code { public string Name; }
    public class Binding : Code
    { public string Identifier; public Code Value, Body; }
    public class Conditional : Code
    { public Code Condition, Then, Else; }
    public class Application : Code
    { public Code Function; public Code[] Args; }
    public class Lambda : Code
    { public string[] ParameterIdentifiers; public Code Body; }
    public class Closure : Lambda
    { public Dictionary<string, Code> Env; }
    abstract public class BuiltInFunc : Code
    { public abstract Code Apply(Code[] args); }

    public class Plus : BuiltInFunc
    {
        public override Code Apply(Code[] args)
        {
            int sum = 0;
            foreach (var item in args)
            { sum += ((Number)item).Value; }
            return new Number { Value = sum };
        }
    }
    public class Equals : BuiltInFunc
    {
        public override Code Apply(Code[] args)
        {
            for (int i = 0; i < args.Length - 1; i++)
            {
                var x = args[i];
                var y = args[i + 1];
                if (x is Number && ((Number)x).Value != ((Number)y).Value
                    || x is Bool && ((Bool)x).Value != ((Bool)y).Value)
                { return new Bool { Value = false }; }
            }
            return new Bool { Value = true };
        }
    }
    public class LessThan : BuiltInFunc
    {
        public override Code Apply(Code[] args)
        {
            for (int i = 0; i < args.Length - 1; i++)
            {
                var x = args[i];
                var y = args[i + 1];
                if (((Number)x).Value >= ((Number)y).Value) 
                { return new Bool { Value = false }; }
            }
            return new Bool { Value = true };
        }
    }
    public class Evaluator
    {
        public Code Evaluate(Code expr)
        { return Evaluate(new Dictionary<string, Code>(), expr); }

        public Code Evaluate(Dictionary<string, Code> env, Code expr)
        {
            if (expr is Number || expr is Bool || expr is BuiltInFunc || expr is Closure)
            { return expr; }

            var l = expr as Lambda;
            if (l != null)
            {
                return new Closure
                {
                    Env = new Dictionary<string, Code>(env),
                    Body = l.Body,
                    ParameterIdentifiers = l.ParameterIdentifiers
                };
            }

            Var v = expr as Var;
            if (v != null)
            { return env[v.Name]; }

            var binding = expr as Binding;
            if (binding != null)
            {
                Code old = null;
                if (env.ContainsKey(binding.Identifier))
                { old = env[binding.Identifier]; }
                env[binding.Identifier] = Evaluate(env, binding.Value);
                var result = Evaluate(env, binding.Body);
                if (old != null) { env[binding.Identifier] = old; }
                return result;
            }

            var conditional = expr as Conditional;
            if (conditional != null)
            {
                var test = Evaluate(env, conditional.Condition) as Bool;
                if (test != null && !test.Value)
                { return Evaluate(env, conditional.Else); }
                else
                { return Evaluate(env, conditional.Then); }
            }

            var app = expr as Application;
            if (app != null)
            {
                var func = Evaluate(env, app.Function);
                var f = func as Closure;
                if (f != null)
                {
                    var envToExtend = f.Env;
                    var len = f.ParameterIdentifiers.Length;
                    var oldValues = new Code[len];
                    for (int i = 0; i < len; i++)
                    {
                        var name = f.ParameterIdentifiers[i];
                        if (envToExtend.ContainsKey(name))
                        { oldValues[i] = envToExtend[name]; }
                        envToExtend[name] = Evaluate(env, app.Args[i]);
                        // Werte die Argumente mit env aus, den
                    } // Körper der Closure mit erweitertem env.
                    var result = Evaluate(envToExtend, f.Body);
                    for (int i = 0; i < len; i++)
                    {
                        var name = f.ParameterIdentifiers[i];
                        if (oldValues[i] != null)
                        { envToExtend[name] = oldValues[i]; }
                    }
                    return result;
                }
                var prim = func as BuiltInFunc;
                if (prim != null)
                {
                    var evaluatedArgs = new Code[app.Args.Length];
                    for (int i = 0; i < evaluatedArgs.Length; i++)
                    { evaluatedArgs[i] = Evaluate(env, app.Args[i]); }
                    return prim.Apply(evaluatedArgs);
                }
                throw new Exception(
                    "Only closures and built-in functions can be applied. Given: "
                    + expr);
            }
            throw new Exception("Unknown subclass of Code: " + expr);
        }
    }
}

Listing 7: Evaluator – datenorientiert mit switch über Type code

using System;
using System.Collections.Generic;

namespace TypeCodes
{
    public enum CodeType
    { Number, Bool, Var, Binding,
      Conditional, Application, Lambda, Closure, BuiltInFunc }

    public abstract class Code
    { public abstract CodeType Type { get; } }
    public class Number : Code
    { public int Value;
      public override CodeType Type
      { get { return CodeType.Number; } } }
    public class Bool : Code
    { public bool Value;
      public override CodeType Type
      { get { return CodeType.Bool; } } }
    public class Var : Code
    { public string Name;
      public override CodeType Type
      { get { return CodeType.Var; } } }

    public class Binding : Code
    {
        public string Identifier; public Code Value, Body;
        public override CodeType Type
        { get { return CodeType.Binding; } }
    }
    public class Conditional : Code
    {
        public Code Condition, Then, Else;
        public override CodeType Type
        { get { return CodeType.Conditional; } }
    }
    public class Application : Code
    {
        public Code Function; public Code[] Args;
        public override CodeType Type
        { get { return CodeType.Application; } }
    }
    public class Lambda : Code
    {
        public string[] ParameterIdentifiers; public Code Body;
        public override CodeType Type
        { get { return CodeType.Lambda; } }
    }
    public class Closure : Lambda
    {
        public Dictionary<string, Code> Env;
        public override CodeType Type
        { get { return CodeType.Closure; } }
    }
    public class BuiltInFunc : Code
    {
        public virtual Code Apply(params Code[] args)
        { throw new Exception(); }
        public override CodeType Type
        { get { return CodeType.BuiltInFunc; } }
    }

    public class Plus : BuiltInFunc
    {
        public override Code Apply(params Code[] args)
        {
            int sum = 0;
            foreach (var item in args)
            { sum += ((Number)item).Value; }
            return new Number { Value = sum };
        }
    }

    public class Equals : BuiltInFunc
    {
        public override Code Apply(params Code[] args)
        {
            for (int i = 0; i < args.Length - 1; i++)
            {
                var x = args[i];
                var y = args[i + 1];
                if (x is Number && ((Number)x).Value != ((Number)y).Value
                    || x is Bool && ((Bool)x).Value != ((Bool)y).Value)
                { return new Bool { Value = false }; }
            }
            return new Bool { Value = true };
        }
    }

    public class LessThan : BuiltInFunc
    {
        public override Code Apply(params Code[] args)
        {
            for (int i = 0; i < args.Length - 1; i++)
            {
                var x = args[i];
                var y = args[i + 1];
                if (x is Number
                    && ((Number)x).Value >= ((Number)y).Value)
                { return new Bool { Value = false }; }
            }
            return new Bool { Value = true };
        }
    }

    public class Evaluator
    {
        public Code Evaluate(Code expr)
        { return Evaluate(new Dictionary<string, Code>(), expr); }

        public Code Evaluate(Dictionary<string, Code> env, Code expr)
        {
            switch (expr.Type)
            {
                case CodeType.Number:
                case CodeType.Bool:
                case CodeType.BuiltInFunc:
                case CodeType.Closure:
                    return expr;
                case CodeType.Lambda:
                    var l = (Lambda)expr;
                    return new Closure
                    {
                        Env = new Dictionary<string, Code>(env),
                        Body = l.Body,
                        ParameterIdentifiers = l.ParameterIdentifiers
                    };
                case CodeType.Var:
                    var v = (Var)expr;
                    return env[v.Name];
                case CodeType.Binding:
                    var bind = (Binding)expr;
                    Code old = null;
                    if (env.ContainsKey(bind.Identifier))
                    { old = env[bind.Identifier]; }
                    env[bind.Identifier] = Evaluate(env, bind.Value);
                    var result = Evaluate(env, bind.Body);
                    if (old != null) { env[bind.Identifier] = old; }
                    return result;
                case CodeType.Conditional:
                    var conditional = (Conditional)expr;
                    var test = Evaluate(env, conditional.Condition) as Bool;
                    if (test != null && !test.Value)
                    { return Evaluate(env, conditional.Else); }
                    else
                    { return Evaluate(env, conditional.Then); }
                case CodeType.Application:
                    var app = (Application)expr;
                    var func = Evaluate(env, app.Function);
                    switch (func.Type)
                    {
                        case CodeType.Closure:
                            var c = (Closure)func;
                            var envToExtend = c.Env;
                            var len = c.ParameterIdentifiers.Length;
                            var oldValues = new Code[len];
                            for (int i = 0; i < len; i++)
                            {
                                var name = c.ParameterIdentifiers[i];
                                if (envToExtend.ContainsKey(name))
                                { oldValues[i] = envToExtend[name]; }
                                envToExtend[name] =
                                    Evaluate(env, app.Args[i]);
                            // Werte die Argumente mit env aus, den
                            } // Körper der Closure mit erweitertem env.
                            var functionResult =
                                Evaluate(envToExtend, c.Body);
                            for (int i = 0; i < len; i++)
                            {
                                var name = c.ParameterIdentifiers[i];
                                if (oldValues[i] != null)
                                { envToExtend[name] = oldValues[i]; }
                            }
                            return functionResult;
                        case CodeType.BuiltInFunc:
                            var b = (BuiltInFunc)func;
                            var length = app.Args.Length;
                            var evaluatedArgs = new Code[length];
                            for (int i = 0; i < length; i++)
                            { evaluatedArgs[i] =
                                Evaluate(env, app.Args[i]); }
                            return b.Apply(evaluatedArgs);
                        default:
                            throw new Exception("Cannot be applied " + func);
                    }
            }
            throw new Exception("Wrong CodeType: " + expr.Type + " (of object " + expr + ")");
        }
    }
}

Listing 8: Evaluator – verhaltensorientiert mit Polymorphie

using System;
using System.Collections.Generic;

namespace Polymorphie
{
    abstract public class Code
    {
        public virtual Code Evaluate(Dictionary<string, Code> env)
        { return this; }
        public virtual Code Apply(Dictionary<string, Code> env,
                Code[] args)
        { throw new Exception("Cannot apply " + this); }
    }

    public class Number : Code { public int Value; }

    public class Bool : Code { public bool Value; }

    public class Var : Code
    {
        public string Name;
        public override Code Evaluate(Dictionary<string, Code> env)
        { return env[Name]; }
    }

    public class Binding : Code
    {
        public string Identifier;
        public Code Value, Body;
        public override Code Evaluate(Dictionary<string, Code> env)
        {
            Code old = null;
            if (env.ContainsKey(Identifier)) { old = env[Identifier]; }

            env[Identifier] = Value.Evaluate(env);
            var result = Body.Evaluate(env);
            if (old != null) { env[Identifier] = old; }
            return result;
        }
    }

    public class Conditional : Code
    {
        public Code Condition, Then, Else;
        public override Code Evaluate(Dictionary<string, Code> env)
        {
            var result = Condition.Evaluate(env) as Bool;
            if (result != null && !result.Value)
            { return Else.Evaluate(env); }
            else
            { return Then.Evaluate(env); }
        }
    }

    public class Application : Code
    {
        public Code Function;
        public Code[] Args;
        public override Code Evaluate(Dictionary<string, Code> env)
        {
            var func = Function.Evaluate(env);
            return func.Apply(env, Args);
        }
    }

    public class Lambda : Code
    {
        public string[] ParameterIdentifiers;
        public Code Body;
        public override Code Evaluate(Dictionary<string, Code> env)
        {
            return new Closure
            {
                Env = new Dictionary<string, Code>(env),
                ParameterIdentifiers = ParameterIdentifiers,
                Body = Body
            };
        }
    }

    public class Closure : Lambda
    {
        public Dictionary<string, Code> Env;
        public override Code Evaluate(Dictionary<string, Code> env)
        { return this; }

        public override Code Apply(Dictionary<string, Code> env, Code[] args)
        {
            var len = ParameterIdentifiers.Length;
            var oldValues = new Code[len];
            for (int i = 0; i < len; i++)
            {
                var name = ParameterIdentifiers[i];
                if (Env.ContainsKey(name))
                { oldValues[i] = Env[name]; }
                Env[name] = args[i].Evaluate(env);
                // Werte die Argumente mit env aus, den
            } // Körper der Closure mit erweitertem env.
            var result = Body.Evaluate(Env);
            for (int i = 0; i < len; i++)
            {
                var name = ParameterIdentifiers[i];
                if (oldValues[i] != null) { Env[name] = oldValues[i]; }
            }
            return result;
        }
    }

    abstract public class BuiltInFunc : Code
    {
        public override Code Apply(Dictionary<string, Code> env, Code[] args)
        {
            var len = args.Length;
            var evaluatedArgs = new Code[len];
            for (int i = 0; i < len; i++)
            { evaluatedArgs[i] = args[i].Evaluate(env); }
            return Apply(evaluatedArgs);
        }
        protected abstract Code Apply(Code[] evaluatedArgs);
    }

    public class Plus : BuiltInFunc
    {
        protected override Code Apply(Code[] args)
        {
            int sum = 0;
            foreach (var item in args)
            { sum += ((Number)item).Value; }
            return new Number { Value = sum };
        }
    }

    public class Equals : BuiltInFunc
    {
        protected override Code Apply(Code[] args)
        {
            for (int i = 0; i < args.Length - 1; i++)
            {
                var x = args[i];
                var y = args[i + 1];
                if (x is Number && ((Number)x).Value != ((Number)y).Value
                    || x is Bool && ((Bool)x).Value != ((Bool)y).Value)
                { return new Bool { Value = false }; }
            }
            return new Bool { Value = true };
        }
    }

    public class LessThan : BuiltInFunc
    {
        protected override Code Apply(Code[] args)
        {
            for (int i = 0; i < args.Length - 1; i++)
            {
                var x = args[i];
                var y = args[i + 1];
                if (((Number)x).Value >= ((Number)y).Value)
                { return new Bool { Value = false }; }
            }
            return new Bool { Value = true };
        }
    }

    public class Evaluator
    {
        public Code Evaluate(Code expr)
        { return expr.Evaluate(new Dictionary<string, Code>()); }
    }
}

Listing 9: Evaluator – verhaltensorientiert mit Visitor pattern

using System;
using System.Collections.Generic;

namespace Visitors
{
    abstract public class Code
    { public abstract Code Accept(Visitor v);}
    public class Number : Code
    {
        public int Value;
        public override Code Accept(Visitor v)
        { return v.Visit(this); } // Visit(Number)
    }
    public class Bool : Code
    {
        public bool Value;
        public override Code Accept(Visitor v)
        { return v.Visit(this); } // Visit(Bool)
    }
    public class Var : Code
    {
        public string Name;
        public override Code Accept(Visitor v)
        { return v.Visit(this); } // usw.
    }
    public class Binding : Code
    {
        public string Identifier; public Code Value, Body;
        public override Code Accept(Visitor v)
        { return v.Visit(this); }
    }
    public class Conditional : Code
    {
        public Code Condition, Then, Else;
        public override Code Accept(Visitor v)
        { return v.Visit(this); }
    }
    public class Application : Code
    {
        public Code Function; public Code[] Args;
        public override Code Accept(Visitor v)
        { return v.Visit(this); }
    }
    public class Lambda : Code
    {
        public string[] ParameterIdentifiers; public Code Body;
        public override Code Accept(Visitor v)
        { return v.Visit(this); }
    }
    public class Closure : Lambda
    {
        public Dictionary<string, Code> Env;
        public override Code Accept(Visitor v)
        { return v.Visit(this); }
    }
    abstract public class BuiltInFunc : Code
    {
        public override Code Accept(Visitor v)
        { return v.Visit(this); }
        public abstract Code Apply(Code[] args);
    }

    public class LessThan : BuiltInFunc
    {
        public override Code Apply(Code[] args)
        {
            for (int i = 0; i < args.Length - 1; i++)
            {
                var x = args[i];
                var y = args[i + 1];
                if (((Number)x).Value >= ((Number)y).Value)
                { return new Bool { Value = false }; }
            }
            return new Bool { Value = true };
        }
    }

    public class Plus : BuiltInFunc
    {
        public override Code Apply(params Code[] args)
        {
            int sum = 0;
            foreach (var item in args)
            { sum += ((Number)item).Value; }
            return new Number { Value = sum };
        }
    }

    public class Equals : BuiltInFunc
    {
        public override Code Apply(params Code[] args)
        {
            for (int i = 0; i < args.Length - 1; i++)
            {
                var x = args[i];
                var y = args[i + 1];
                if (x is Number && ((Number)x).Value != ((Number)y).Value
                    || x is Bool && ((Bool)x).Value != ((Bool)y).Value)
                { return new Bool { Value = false }; }
            }
            return new Bool { Value = true };
        }
    }

    abstract public class Visitor
    {
        public virtual Code Visit(Number expr)
        { return VisitDefault(expr); }
        public virtual Code Visit(Bool expr)
        { return VisitDefault(expr); }
        public virtual Code Visit(Var expr)
        { return VisitDefault(expr); }
        public virtual Code Visit(Binding expr)
        { return VisitDefault(expr); }
        public virtual Code Visit(Conditional expr) 
        { return VisitDefault(expr); }
        public virtual Code Visit(Application expr)
        { return VisitDefault(expr); }
        public virtual Code Visit(Lambda expr)
        { return VisitDefault(expr); }
        public virtual Code Visit(Closure expr)
        { return VisitDefault(expr); }
        public virtual Code Visit(BuiltInFunc expr)
        { return VisitDefault(expr); }
        protected abstract Code VisitDefault(Code expr);
    }

    public class EvaluationVisitor : Visitor
    {
        Dictionary<string, Code> env;
        public EvaluationVisitor()
          : this(new Dictionary<string, Code>()) { }
        public EvaluationVisitor(Dictionary<string, Code> env)
        { this.env = env; }

        protected override Code VisitDefault(Code expr)
        { return expr; }

        public override Code Visit(Var expr)
        { return env[expr.Name]; }

        public override Code Visit(Lambda expr)
        {
            return new Closure
            {
                Env = new Dictionary<string, Code>(env),
                Body = expr.Body,
                ParameterIdentifiers = expr.ParameterIdentifiers
            };
        }

        public override Code Visit(Binding expr)
        {
            Code old = null;
            if (env.ContainsKey(expr.Identifier))
            { old = env[expr.Identifier]; }
            env[expr.Identifier] = expr.Value.Accept(this);
            var result = expr.Body.Accept(this);
            if (old != null) { env[expr.Identifier] = old; }
            return result;
        }

        public override Code Visit(Conditional expr)
        {
            var result = expr.Condition.Accept(this) as Bool;
            if (result != null && !result.Value)
            { return expr.Else.Accept(this); }
            else
            { return expr.Then.Accept(this); }
        }

        public override Code Visit(Application expr)
        {
            var evaluatedFunction = expr.Function.Accept(this);
            var appVisitor = new ApplicationVisitor(this, env, expr);
            return evaluatedFunction.Accept(appVisitor);
        }
    }

    public class ApplicationVisitor : Visitor
    {
        Visitor parentVisitor;
        Application app;
        Dictionary<string, Code> env;

        public ApplicationVisitor(Visitor parentVisitor,
                        Dictionary<string, Code> env, Application app)
        {
            this.parentVisitor = parentVisitor;
            this.env = env;
            this.app = app;
        }

        public override Code Visit(Closure expr)
        {
            var envToExtend = expr.Env;
            var len = expr.ParameterIdentifiers.Length;
            var oldValues = new Code[len];
            for (int i = 0; i < len; i++)
            {
                var name = expr.ParameterIdentifiers[i];
                if (envToExtend.ContainsKey(name))
                { oldValues[i] = envToExtend[name]; }
                envToExtend[name] = app.Args[i].Accept(parentVisitor);
            } // Argumente mit env auswerten, Körper mit neuem env.
            var result = expr.Body.Accept( // Dafür neuer Visitor:
                    new EvaluationVisitor(envToExtend));
            for (int i = 0; i < len; i++)
            {
                var name = expr.ParameterIdentifiers[i];
                if (oldValues[i] != null)
                { envToExtend[name] = oldValues[i]; }
            }
            return result;
        }

        public override Code Visit(BuiltInFunc expr)
        {
            var len = app.Args.Length;
            var args = new Code[len];
            for (int i = 0; i < len; i++)
            { args[i] = app.Args[i].Accept(parentVisitor); }
            return expr.Apply(args);
        }

        protected override Code VisitDefault(Code expr)
        { throw new Exception("Cannot apply " + expr); }
    }

    public class Evaluator
    {
        public Code Evaluate(Code expr)
        { return expr.Accept(new EvaluationVisitor()); }
    }
}

Listing 10: Test der Evaluator-Implementierungen in C#

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

// Stellt eine Sammlung von Tests dar, die eine Evaluator-Implementierung überprüfen.
// Die Typparameter müssen den zu testenden Klassen entsprechen.
// Der Evaluator kapselt die Strategie, indem die Evaluate-Methode auf den Ausdruck angewendet und das Ergebnis geprüft wird.
// Die Klassen werden instanziiert und zu Test-Ausdrücken zusammengesetzt.
// Die statischen Methoden stellen die Tests dar. In Unterklassen müssen sie aufgerufen werden.
// Als Kommentar der einzelnen Tests steht ein exemplarischer Scheme-Ausdruck, der den Test darstellt.
// Der Test wird für gewöhnlich mit mehreren Prüfungen ausgeführt.
// (assert= actual expected) ist eine fiktive Funktion, die der Assert.AreEqual-Methode des Test-Frameworks enspricht.
public class DynamicTests<Code, Evaluator, LessThan, Equals, Plus, Number, Bool, Var, Binding, Conditional, Application, Lambda>
    where Evaluator : new()
    where LessThan : Code, new()
    where Equals : Code, new()
    where Plus : Code, new()
    where Number : Code, new()
    where Bool : Code, new()
    where Var : Code, new()
    where Binding : Code, new()
    where Conditional : Code, new()
    where Application : Code, new()
    where Lambda : Code, new()
{
    // (assert= (let ([x 20]) (+ x x 4))
    //                    44)
    public static void LetPlus()
    {
        dynamic bind = new Binding();
        dynamic variable = new Var();
        dynamic plus = new Plus();
        dynamic apply = new Application();
        dynamic constant = new Number();
        dynamic init = new Number();

        variable.Name = "x";
        bind.Identifier = "x";
        bind.Value = init;
        apply.Function = plus;
        apply.Args = new Code[] { variable, variable, constant };
        bind.Body = apply;

        dynamic ev = new Evaluator();
        for (int i = -100; i < 100; i++)
        {
            for (int k = -100; k < 100; k++)
            {
                constant.Value = i;
                init.Value = k;
                dynamic res = ev.Evaluate(bind);
                Assert.AreEqual(2 * k + i, res.Value);
            }
        }
    }

    // (assert= ((lambda (a b) (if (< a b ) a b)) 1 2)
    //                   1)
    public static void LambdaIfLess()
    {
        dynamic var1 = new Var();
        dynamic var2 = new Var();
        dynamic lt = new LessThan();
        dynamic min = new Lambda();
        dynamic cond = new Conditional();
        dynamic apply1 = new Application();
        dynamic apply2 = new Application();
        dynamic num1 = new Number();
        dynamic num2 = new Number();

        var1.Name = "a";
        var2.Name = "b";
        min.ParameterIdentifiers = new[] { "a", "b", };
        min.Body = cond;
        cond.Condition = apply1;
        apply1.Function = lt;
        apply1.Args = new Code[] { var1, var2 };
        cond.Then = var1;
        cond.Else = var2;

        apply2.Function = min;
        num1.Value = 1;
        num2.Value = 2;
        apply2.Args = new Code[] { num1, num2 };

        dynamic eval = new Evaluator();

        for (int i = -100; i < 100; i++)
        {
            for (int k = -100; k < 100; k++)
            {
                num1.Value = i;
                num2.Value = k;
                dynamic result = eval.Evaluate(apply2);
                Assert.AreEqual(Math.Min(i, k), result.Value);
            }
        }
    }

    // (assert=
    //   ((lambda (cont x) (if (= x 0) 1 (+ x (cont cont (+ x -1)))))
    //     (lambda (cont x) (if (= x 0) 1 (+ x (cont cont (+ x -1)))))
    //    4)
    //    11) // Wie Fakultät nur mit + statt *: 1, 2, 4, 7, 11, 16, 22, 29, ...
    public void ContinuationRecursion()
    {
        dynamic fun = new Lambda();
        dynamic cont = new Var();
        dynamic x = new Var();
        dynamic eq = new Equals();
        dynamic input = new Number();
        dynamic cond = new Conditional();
        dynamic recurse = new Application();
        dynamic plus = new Plus();
        dynamic applyPlus = new Application();
        dynamic applyEq = new Application();
        dynamic subtractOne = new Application();
        dynamic negOne = new Number();
        dynamic zero = new Number();
        dynamic one = new Number();
        dynamic test = new Application();

        zero.Value = 0;
        one.Value = 1;
        negOne.Value = -1;
        x.Name = "x";
        cont.Name = "cont";

        fun.ParameterIdentifiers = new[] { "cont", "x" };
        fun.Body = cond;

        applyEq.Function = eq;
        applyEq.Args = new Code[] { x, zero };

        cond.Condition = applyEq;
        cond.Then = one;
        cond.Else = applyPlus;
        applyPlus.Function = plus;
        applyPlus.Args = new Code[] { x, recurse };
        recurse.Function = cont;
        recurse.Args = new Code[] { cont, subtractOne };
        subtractOne.Function = plus;
        subtractOne.Args = new Code[] { x, negOne };

        test.Function = fun;
        test.Args = new Code[] { fun, input };

        dynamic eval = new Evaluator();

        for (int i = 0; i < 100; i++)
        {
            input.Value = i;
            dynamic result = eval.Evaluate(test);
            var sum = 1;
            for (int counter = 1; counter <= i; counter++)
            { sum += counter; }
            Assert.AreEqual(sum, result.Value);
        }
    }

    // cons = (lambda (hd tl) (lambda (takeHead)(if takeHead hd tl)))
    // head = (lambda (consCell) (consCell true))
    // tail = (lambda (consCell) (consCell false))
    // isEmpty = (lambda (consCell) (if consCell #f #t))
    // oneTwo = (cons 1 (cons 2 #f))
    // (assert= (head oneTwo) 1)
    // (assert= (head (tail oneTwo)) 2)
    // (assert= (tail (tail oneTwo)) #f)
    // (assert= (isEmpty oneTwo) #f)
    // (assert= (isEmpty (tail oneTwo)) #f)
    // (assert= (isEmpty (tail (tail oneTwo))) #t)
    public void ListClosure()
    {
        dynamic cons = new Lambda();
        dynamic consSelect = new Lambda();
        dynamic consSelectIf = new Conditional();
        dynamic takeHead = new Var();
        dynamic headVar = new Var();
        dynamic tailVar = new Var();
        takeHead.Name = "takeHead";
        headVar.Name = "head";
        tailVar.Name = "tail";
        cons.ParameterIdentifiers = new[] { "head", "tail" };
        cons.Body = consSelect;
        consSelect.ParameterIdentifiers = new[] { "takeHead" };
        consSelect.Body = consSelectIf;
        consSelectIf.Condition = takeHead;
        consSelectIf.Then = headVar;
        consSelectIf.Else = tailVar;

        dynamic head = new Lambda();
        dynamic headApp = new Application();
        dynamic trueBool = new Bool();
        dynamic consCellVar = new Var();
        consCellVar.Name = "consCell";
        trueBool.Value = true;

        head.ParameterIdentifiers = new[] { "consCell" };
        head.Body = headApp;
        headApp.Function = consCellVar;
        headApp.Args = new Code[] { trueBool };

        dynamic tail = new Lambda();
        dynamic tailApp = new Application();
        dynamic falseBool = new Bool();
        falseBool.Value = false;

        tail.ParameterIdentifiers = new[] { "consCell" };
        tail.Body = tailApp;
        tailApp.Function = consCellVar;
        tailApp.Args = new Code[] { falseBool };

        dynamic isEmpty = new Lambda();
        dynamic isEmptyIf = new Conditional();
        dynamic xs = new Var();
        xs.Name = "xs";
        isEmpty.ParameterIdentifiers = new[] { "xs" };
        isEmpty.Body = isEmptyIf;
        isEmptyIf.Condition = xs;
        isEmptyIf.Then = falseBool;
        isEmptyIf.Else = trueBool;

        dynamic one = new Number();
        one.Value = 1;
        dynamic two = new Number();
        two.Value = 2;

        dynamic twoList = new Application();
        twoList.Function = cons;
        twoList.Args = new Code[] { two, falseBool };
        dynamic oneTwo = new Application();
        oneTwo.Function = cons;
        oneTwo.Args = new Code[] { one, twoList };

        dynamic ev = new Evaluator();
        dynamic headTest = new Application();
        headTest.Function = head;
        headTest.Args = new Code[] { oneTwo };

        dynamic num = ev.Evaluate(headTest);
        Assert.AreEqual(1, num.Value);

        dynamic tailOfOneTwo = new Application();
        tailOfOneTwo.Function = tail;
        tailOfOneTwo.Args = new Code[] { oneTwo };

        dynamic headOfTailTest = new Application();
        headOfTailTest.Function = head;
        headOfTailTest.Args = new Code[] { tailOfOneTwo };

        num = ev.Evaluate(headOfTailTest);
        Assert.AreEqual(2, num.Value);

        dynamic tailOfTailTest = new Application();
        tailOfTailTest.Function = tail;
        tailOfTailTest.Args = new Code[] { tailOfOneTwo };

        dynamic empty = ev.Evaluate(tailOfTailTest);
        Assert.AreEqual(false, empty.Value);

        dynamic isEmptyTest = new Application();
        isEmptyTest.Function = isEmpty;

        isEmptyTest.Args = new Code[] { oneTwo };
        empty = ev.Evaluate(isEmptyTest);
        Assert.AreEqual(false, empty.Value);

        isEmptyTest.Args = new Code[] { tailOfOneTwo };
        empty = ev.Evaluate(isEmptyTest);
        Assert.AreEqual(false, empty.Value);

        isEmptyTest.Args = new Code[] { tailOfTailTest };
        empty = ev.Evaluate(isEmptyTest);
        Assert.AreEqual(true, empty.Value);
    }
}

// Es folgen die Tests der einzelnen Implementierungen. Sie befinden sich in einem Namespace,
// damit dort die Klassen mit using importiert werden können.
// Dies sind die Typparameter der Test-Sammlung.
// Die Namen der Test-Methoden enthalten den Namen des Implementierungsansatzes,
// um schnell zu sehen, welcher Implementierungsaspekt welches Ansatzes fehlerhaft war.
namespace TypetestsTest
{
    using Typtests;
    [TestClass]
    public class Test : DynamicTests<Code, Evaluator, LessThan, Equals, Plus, Number, Bool, Var, Binding, Conditional, Application, Lambda>
    {
        [TestMethod]
        public void TyptestsLambdaIfLess() { LambdaIfLess(); }
        [TestMethod]
        public void TyptestsLetPlus() { LetPlus(); }
        [TestMethod]
        public void TyptestsContinuationRecursion() { ContinuationRecursion(); }
        [TestMethod]
        public void TyptestsClosure() { ListClosure(); }
    }
}

namespace TypeCodesTest
{
    using TypeCodes;
    [TestClass]
    public class Test : DynamicTests<Code, Evaluator, LessThan, Equals, Plus, Number, Bool, Var, Binding, Conditional, Application, Lambda>
    {
        [TestMethod]
        public void TypeCodesLambdaIfLess() { LambdaIfLess(); }
        [TestMethod]
        public void TypeCodesLetPlus() { LetPlus(); }
        [TestMethod]
        public void TypeCodesContinuationRecursion() { ContinuationRecursion(); }
        [TestMethod]
        public void TypeCodesClosure() { ListClosure(); }
    }
}

namespace PolymorphieTest
{
    using Polymorphie;
    [TestClass]
    public class Test : DynamicTests<Code, Evaluator, LessThan, Equals, Plus, Number, Bool, Var, Binding, Conditional, Application, Lambda>
    {
        [TestMethod]
        public void PolymorphieLambdaIfLess() { LambdaIfLess(); }
        [TestMethod]
        public void PolymorphieLetPlus() { LetPlus(); }
        [TestMethod]
        public void PolymorphieContinuationRecursion() { ContinuationRecursion(); }
        [TestMethod]
        public void PolymorphieClosure() { ListClosure(); }
    }
}

namespace VisitorsTest
{
    using Visitors;
    [TestClass]
    public class Test : DynamicTests<Code, Evaluator, LessThan, Equals, Plus, Number, Bool, Var, Binding, Conditional, Application, Lambda>
    {
        [TestMethod]
        public void VisitorsLambdaIfLess() { LambdaIfLess(); }
        [TestMethod]
        public void VisitorsLetPlus() { LetPlus(); }
        [TestMethod]
        public void VisitorsContinuationRecursion() { ContinuationRecursion(); }
        [TestMethod]
        public void VisitorsClosure() { ListClosure(); }
    }
}