Generische funktionale Programmierung 2 Template Haskell

Fachbereich 12
Mathematik und Informatik
Philipps-Universität Marburg
Autor: Johannes Juch
Matr.-Nr.: 1307290
Rosenstraße 7
35037 Marburg
E-Mail: [email protected]
Tel.: 06421/23538
Generische funktionale Programmierung 2
Template Haskell
Tim Sheard, Simon Peyton Jones: "Template Meta-programming for Haskell"
Ian Lynagh: "Template Haskell: A Report From The Field"
Seminararbeit von Johannes Juch
Im Rahmen des Seminars „Konzepte für Programmiersprachen“
unter der Leitung von Prof. Dr. Rita Loogen
Kurzzusammenfassung
Mit Template Haskell wurde die rein funktionale Sprache Haskell erweitert, um MetaProgrammierung zur Compile-Zeit zu ermöglichen. In dieser Arbeit werden die Mittel und
Werkzeuge zur algorithmischen Konstruktion von Programmen mit Template Haskell
vorgestellt. Es wird gezeigt, wie man mit Template Haskell Code zur Compile-Zeit generiert
und sich ein erzeugtes Programm bestimmten Anforderungen anpasst, z.B. der Größe der zu
bearbeitenden Datenstruktur. Danach werden vermeintliche Probleme ,Vor- und Nachteile
diskutiert, sowie Ansätze zur deren Lösung oder Umgehung.
KAPITEL 1
EINLEITUNG..................................................................................... 2
1.1 Motivation ........................................................................................................................... 2
1.2 Grundlagen und Aufbau der Arbeit................................................................................. 2
KAPITEL 2
TEMPLATE HASKELL: DIE NEUEN FÄHIGKEITEN....................... 4
2.1 Quasi Quotation und der Splice-Operator '$' ................................................................. 4
2.2 Die Syntax-Generator Funktionen und die Quotation Monade .................................... 6
2.3 Deklarationen und Vergegenständlichung (Reification) ................................................ 6
KAPITEL 3
TYPISIERUNG IN TEMPLATE HASKELL........................................ 7
3.1 Ausdrücke ........................................................................................................................... 8
3.2 Deklarationen ................................................................................................................... 10
4 BEISPIELE UND ERLÄUTERUNGEN.................................................................. 11
4.1 Quasi Quotation vs Syntax-Generator Funktionen ...................................................... 11
4.2 Scoping .............................................................................................................................. 12
4.3 Eigenschaften der Quotation Monade............................................................................ 14
5 TEMPLATE HASKELL IN DER ANWENDUNG ................................................... 16
5.1 Expandieren von Deklarationen des FFI ....................................................................... 16
5.2 Optimierung durch "Unrolling"..................................................................................... 17
KAPITEL 6
FAZIT .............................................................................................. 19
ANHANG A: ALGEBRAISCHE DATENTYPREPRÄSENTATION VON HASKELL 21
ANHANG B: MONADISCHE SYNTAX-OPERATOREN.......................................... 22
1
Kapitel 1 Einleitung
1.1 Motivation
Meta-Programmierung zur Compile-Zeit und die dadurch mögliche algorithmische
Konstruktion von Programmen zur Compile-Zeit eröffnen dem Programmierer die
Möglichkeit zur Entwicklung von polymorphen Programmen, da der Typ eines durch MetaProgramm erzeugtes Programms erst zur Compile-Zeit des Meta-Programms fest steht. Des
Weiteren können Benutzer gerichtete Optimierungen in der Compilierung durchgeführt
werden. In der Vergangenheit wurde viel mit Laufzeit Meta-Programmierung experimentiert,
während die Compile-Zeit Meta-Programmierung weniger Interesse auf sich zog (Ausnahme:
Scheme community). Innerhalb kurzer Zeit haben sich die Art und Weisen, wie "Templates"
in der Programmierung verwendet werden, beeindruckend ausgeweitet.
Viele interessante Optimierungen sprechen leider eine zu kleine Zielgruppe an, um die Kosten
ihrer Entwicklung zu rechtfertigen. Die Alternative ist es, dem Programmierer die
Möglichkeit zu geben seine Programme gezielt zu manipulieren und so eigene Optimierungen
mit denen des Compilers zu verknüpfen. Der Programmierer erhält die Möglichkeit, dem
Compiler verschiedene Tricks durch seine Programme beizubringen, was eine individuelle
und flexiblere Optimierung bedeutet.
Oft ist es auch einfacher ein Programm zu schreiben, das ein Programm schreibt, als das
Programm direkt zu schreiben. Mit Template Haskell erhält der Programmierer die
Möglichkeit seine Programme, oder Teile davon, berechnen zu lassen, als sie selbst zu
schreiben.
In der Vorstellung der Entwickler könnte Template Haskell für viele Sachen und Probleme
verwendet werden, u.a. um
•
algorithmische Konstruktion von Programmen
•
Abstraktionen, die über den Abstraktionsgrad der Sprache hinaus gehen
•
bedingte, programmgesteuerte Compilierung
zu ermöglichen.
1.2 Grundlagen und Aufbau der Arbeit
Die Grundlagen für den Entwurf von Template Haskell sind zum ersten die rein funktionale
und streng typisierte Sprache Haskell, und eine Erweiterung in Form eines SchablonenSystems. Die Erweiterung kann sowohl als ein Schablonen-System, als auch als typsicheres
Makrosystem, für die Basissprache Haskell gesehen werden. Da Haskell eine streng typisierte
2
Sprache ist, benötigt man eine Typüberprüfung auf verschiedenen Ebenen, um die generelle
Typüberprüfung der Module mit denen der Compile-Zeit-Berechnungen zu synchronisieren
(Kapitel 4). Diese Ebenenüberprüfung sorgt dafür, dass alle Laufzeitberechnungen auf ihre
Typenkonformität überprüft wurden und somit sicher sind. Zusätzlich werden von der
Ebenenüberprüfung Codegeneratoren bereitgestellt, die, als gewöhnliche Programme
geschrieben, die Einführung von abhängigen Typen erfordern würden. Durch diese
Codegeneratoren in der Typüberprüfung bleibt die Sprache ausdrucksstark und einfach.
Es werden neue syntaktische Elemente und Annotationen eingeführt, die notwendig sind, um
festlegen zu können, welche Programmteile (Ausdrücke, Deklarationen,...) wann ausgeführt
werden sollen. Zu diesen gehören die sogenannten "Quasi-Quotations" und die "Splices", die
mit dem Symbol $ eingeleitet werden (Kapitel 2).
Die Repräsentation von gewöhnlichem Haskell Quellcode geschieht über neu eingeführte
algebraische Datenstrukturen. Dies und die Tatsache, dass in diesem Ansatz die Sprache der
Erweiterung mit der Basissprache übereinstimmt, eben Haskell, ermöglicht es, die bereits
existierenden Mechanismen (Fallunterscheidung, Pattern Matching) zu nutzen, um Code zu
generieren, kontrollieren und zu manipulieren. Weitere Meta-Programm-Fähigkeiten werden
durch die sogenannte Quotation Monade bereitgestellt. Eine monadische Bibliothek, die auf
algebraischen Datentypen aufsetzt, stellt monadische Syntaxoperatoren bereit. Diese
Bibliothek kapselt Meta-Programm-Eigenschaften, wie Fehlerausgabe, Namengenerierung
und Programmverdinglichung (in dieser Arbeit weiterhin Reification genannt), und stellt eine
einfache Schnittstelle zu deren Nutzung bereit.
Die oben bereits erwähnten "Quasi Quotations" setzen wiederum auf der monadischen
Bibliothek auf. Sie übersetzen Code in eine monadische Berechnung, was die Erhaltung
statischer Gültigkeiten einschließt.
Programm-Reification kann dazu eingesetzt werden, die vom Programmierer geschriebenen
Komponenten, auf ihre syntaktische Struktur zu analysieren und zu manipulieren. Dies ist vor
allem dann hilfreich, wenn man sogenannten "boilerplate"1 Code direkt von der
Datentypdeklaration ableiten möchte. „Boilerplate“ steht für Code der zur Traversierung von
Datenstrukturen benötigt wird. Dieser kann gerade bei wechselseitig rekursiven Datentypen
sehr umfangreich und bei Änderungen der Strukturen sehr fehleranfällig sein. Deshalb ist es
sinnvoll diesen Code direkt und automatisch von der Datenstruktur abzuleiten, so dass sich
der Programmierer auf die wesentlichen Details seines Programms konzentrieren kann.
1
Mehr zu boilerplate Code in: "Scrap your boilerplate: a practical design pattern for generic programming” by
Ralf Lämmel and Simon Peyton-Jones, erschienen in Sitzungsbericht der TLDI 2003, ACM Press.
3
Kapitel 2 Template Haskell: Die neuen Fähigkeiten
In diesem Kapitel werden die grundlegenden Mittel zur Template Meta-Programmierung mit
Template Haskell vorgestellt und mit Beispielen deren Nutzen aufgezeigt.
2.1 Quasi Quotation und der Splice-Operator '$'
Die „Quasi Quotes“ beinhalten gewöhnliche Haskell Syntax Fragmente, sie sind die
eigentlichen "Schablonen" in Template Haskell. Der Quasi-Quote Mechanismus setzt auf der
monadischen Bibliothek, die Template Haskell mitbringt, auf. Die Quasi Quotations haben
immer einen der Typen ExpQ, DecQ oder Type d.h. sie "heben" den Haskellcode in ihrem
Inneren auf diesen monadischen abstrakten Datentyp. Es sei hier schon erwähnt, dass der Typ
ExpQ ein Synonym für Q Exp ist. Quasi Quotations dürfen folgenden Inhalt haben:
•
[| ... |], wobei "..." ein Ausdruck ist; die Quotation hat dann den Typ ExpQ.
•
[d| ... |], wobei "..." eine Liste von Deklarationen höchster Ebene ist; die
Quotation hat dann Typ Q [Dec].
•
[t| ... |], wobei "..." ein Typ ist; die Quotation hat dann Typ Type.
Die "Quasi Quotes" übersetzen die Ausdrücke in Code auf Objektebene, der bei letztendlicher
Ausführung des Programms zu einer Repräsentation der Ausdrücke in Form abstrakter
Syntaxbäume führt, die im Modul Language.Haskell.TH.THSyntax definiert sind.
Ein „Splice“ kann an verschiedenen Stellen gesetzt werden und besagt lediglich, dass der
einbezogene Code zur Compile-Zeit ausgeführt werden soll.
Dabei kann der Code entweder
•
ein Ausdruck, der den Typ Q Exp hat,
•
eine Liste von Deklaration auf höchster Ebene, die den Typ Q [Dec] hat,
•
oder ein Typ, der den Typ Type hat sein.
Es ist auf die syntaktische Besonderheit zu achten, dass kein Leerzeichen zwischen dem $ und
dem zu „splicenden“ Code sein darf, sonst wird das „Splice-Symbol“ vom Compiler nicht als
solches erkannt.
In meinem ersten Beispiel für die Verwendung von [| ... |] und '$' geht es um die Ausgabe des
aktuellen Datums, in Form einer printf Funktion, wie es sie in C gibt.
printf "Heute ist der %d. %s %d" day month year
Die Funktion printf bekommt einen String und zwei weitere Parameter übergeben, die den
String vervollständigen. In Haskell können wir diese Funktion nicht implementieren, in
Template Haskell verwenden wir den $-Operator folgendermaßen:
$(printf "Heute ist der %d. %s %d") day month year
4
Nach Typüberprüfung und Compilierung erhalten wir den Ausdruck:
( \d0 -> \s1 -> \d2 ->
"Heute ist der " ++ d0 ++ ". " ++ s1 ++ d2)
Die Lambda Abstraktion wird nun erneut einer Typüberprüfung unterzogen und auf day,
month und year angewandt. Natürlich fehlt uns jetzt noch die Deklaration der Meta-Funktion
printf:
printf :: String -> ExpQ
printf s = gen (parse s)
Die Hilfsfunktion parse zerlegt den formatierten String in eine Liste des Datentyps Format.
parse ist eine gewöhnliche Haskell Funktion, die Funktion gen dagegen verwendet Quasi
Quotation:
data Format = D | S | L String
parse :: String -> [Format]
parse s = ...
gen :: [Format] -> ExpQ -> ExpQ
gen [] ex
= ex
gen (D
:xs) ex
= [| d -> $(gen xs [| $ex++show d |]) |]
gen (S
:xs) ex
= [| s -> $(gen xs [| $ex++s |]) |]
gen (L s
:xs) ex
= gen xs [| $ex ++ $(lift s) |]
Durch die $-Operatoren werden die Aufrufe von gen zur Compile-Zeit ausgeführt und in die
Quasi Quotations eingefügt. Das zweite Argument (ex) benötigen wir als Akkumulator für die
rekursiven Aufrufe von gen. Im obigen Beispiel zum Aufruf von printf sieht die
Auswertung folgendermaßen aus. Nachdem die Hilfsfunktion parse das erste Listenelement
vom Typ Format erzeugt hat, wird die Funktion gen mit diesem Aufgerufen. Die Funktion
gen erzeugt Code der durch die "Splices" innerhalb der Quasi Quotations dafür sorgt, dass die
Auswertung des erzeugten Codes ebenfalls zur Compile-Zeit stattfindet. Die Variablen
innerhalb der zweiten Argumente der rekursiven Aufrufe von gen sind eindeutig über die
Lambda Abstraktionen gebunden (vgl. S.13).
Eine der globalen Prinzipien von Template Haskell ist, dass die Quatation – Splice
Aufhebung immer gilt
•
bei Ausdrücken: $[| Exp |] = Exp
•
bei Deklarationen: $[| Dec |] = Dec
•
und bei Typen: $[| Typ |] = Typ.
5
2.2 Die Syntax-Generator Funktionen und die Quotation Monade
In Kapitel 4.1 werde ich zeigen, dass wir mit den Quasi Quotations und dem Splice-Operator
nicht den vollen Umfang der Möglichkeiten der Meta-Programmierung erreichen. Wir
benötigen eine Methode, mit der wir Haskell Syntaxbäume direkt „per Hand“ konstruieren
können, um flexibel Code zu generieren. Diese Methode stellt Template Haskell in Form
einer ganzen Familie von Syntax-Generator Funktionen bereitstellt. Auszüge aus dem Modul
Language.Haskell.TH.THSyntax kann im Anhängen A und B eingesehen werden. Wie wir
noch sehen werden, bezahlen wir den Gewinn an Flexibilität mit Übersichtlichkeit des Codes,
da die Syntax-Generator Funktionen eine Abstraktion von Haskellcode darstellen.
Die Quotation Monade Q kapselt verschiedene Fähigkeiten, wie die Erzeugung neuer Namen
(vgl. Kapitel 4.3), Fehlerbehandlung und Input/Output-Methoden. Eine Bibliothek stellt eine
einfache Schnittstelle für Zugriffe auf die untere Ebene der algebraischen Datentypen bereit.
2.3 Deklarationen und Vergegenständlichung (Reification)
Die Vergegenständlichung von Datenstrukturen, die in dieser Arbeit weiterhin Reification
genannt wird, ermöglicht es Programmen, deren eigene Strukturen zur Compile-Zeit zu
untersuchen. Das heißt, dass dem Programmierer erlaubt wird, auf die compilerinternen
Symboltabellen zuzugreifen. Reification ist ein nützliches Instrument, z.B. um so genannten
„boilerplate“ Code zu erzeugen, oder nützliche Fehlermeldungen zu erzeugen. "Boilerplate"
Code wird z.B. mit der "deriving" Anweisung selbstständig vom Compiler erzeugt, was
allerdings nur für einige Standardklassen (Eq, Ord,...) unterstützt wird. Durch Template
Haskells Fähigkeit zur Reification kann man algorithmisch Code erzeugen, der von der
Struktur einer Datenstruktur abhängt.
Es werden vier Operatoren zur Reification vorgestellt: reifyType, reifyDecl, reifyFixity,
und reifyLocn, die jeweils ein Ergebnis in der Quotation Monade liefern.
•
reifyType bekommt den Bezeichner einer Funktion oder eines Datenkonstruktors
und gibt den Typ der Dateneinheit in Form eines Wertes vom Typ TH.Syntax.Type
zurück.
•
Analog bekommt reifyDecl den Bezeichner eines Typs und gibt eine Repräsentation
(eine Datenstruktur) der Deklaration des Typs in Form eines Wertes vom Typ
TH.THSyntax.Decl zurück.
•
reifyLocn gibt die Position im Quelltext, in der es sich befindet, in Form eines
Wertes vom Typ Q String zurück.
•
reifyFixity gibt die Präzedenz seines Argumentes zurück.
6
In der zweiten Version von Template Haskell, die im November 2003 erschien, hat sich
Reification stark verändert. In der ersten Version war Reification ein Sprachkonstrukt und
keine Funktion. Jetzt gibt es noch eine einfache Funktion reify, die den Namen übergeben
bekommt und Informationen über das Element aus der Symboltabelle und Typinformationen
des Compilers zurückgibt.
reify :: Name -> Q Info
Name ist ein neuer abstrakter Datentyp, und Info ist ebenfalls ein neu eingeführter Datentyp
über dessen Konstruktoren die jeweiligen Informationen zurückgegeben werden.
Zur Reification sind noch einige Fragen offen, auf die im Kapitel 4 noch eingegangen wird.
Kapitel 3 Typisierung in Template Haskell
Template Haskell ist streng typisiert. Gewöhnlich wird bei Programmen streng typisierter
Sprachen erst die Typenüberprüfung durchgeführt und dann folgt die Compilierung. Die
Typisierung eines Programms in Template Haskell stellt ein Problem dar, weil der Typ eines
"Splice"-Ausdrucks zur Compile-Zeit noch von seinen Argumenten abhängen kann. Hierzu
betrachten wir noch einmal das Beispiel aus Kapitel 2.1:
$(printf "Heute ist der %d. %s %d") day month year
In dieser Form kann der "Splice" nicht auf seinen Typ überprüft werden, da sein Typ von dem
Wert seines Stringargumentes abhängt. Offensichtlich ist die Typüberprüfung mit der
(compile-zeit) Ausführung eng verwoben und die Notwendigkeit von bestimmten
Typisierungsregeln ergibt sich. Die Situation in Template Haskell erfordert eine
Typüberprüfung auf verschiedenen Ebenen.
Die Vorgehensweise in unserem Beispiel ist nun folgendermaßen:
•
erstens, überprüfe den Rumpf des "Splice"-Ausdrucks; hier:
printf "Heute ist der %d. %s %d"
•
zweitens, compiliere den Rumpf, führe ihn aus und füge das Ergebnis ein; wir erhalten
dann:(\d0 -> \s1 -> \d2 ->"Heute ist der " ++ d0 ++ ". " ++ s1 ++ d2)
day year month
•
drittens, überprüfe das resultierende gesamte Programm wie gewöhnlich.
Typisierungsregeln legen fest, wie, und vor allem wann, die Ausdrücke, Variablen u.a.
unter Berücksichtigung ihrer Position zu typisieren sind. Dazu verwendet der Compiler
Ebenen und Zustände. Während der Typüberprüfung befindet sich der Compiler immer in
einem der drei Zustände C, B, oder S.
7
Abbildung 1: Typisierungszustände in Template Haskell
•
C (Compilieren) steht für den normalen Compilierungszustand, den der Compiler ohne
Meta-Operatoren nicht verlässt.
•
In den Zustand B (Bracket) gerät der Compiler, wenn er in eine Quasi Quotation
eintritt.
•
Den Zustand S (Splice) nimmt der Compiler ein, wenn er auf einen "Splice"-Ausdruck
trifft.
Die Typisierungszustände für Template Haskell werden in Abbildung 1 in einem Diagramm
dargestellt. Beginnend Ebene 0, zählt der Compiler mit, in welcher Ebene er sich befindet.
Die Ebene wird inkrementiert, falls er innerhalb einer Quasi Quotation arbeitet, und
dekrementiert, falls er einen "Splice"-Ausdruck bearbeitet. Die Ebenen sind nötig, um
zwischen top-level „Splices“ und „Splices“ innerhalb von Quasi Quotations unterscheiden zu
können. Dies kann gut an Hand Abbildung 1 nachvollzogen werden.
3.1 Ausdrücke
Abbildung 2 zeigt die Typisierungsregeln für Ausdrücke. Typisierungsregeln haben die
generelle konventionelle Form:
Γ ist eine Umgebung, die Variablen auf ihre Typen abbildet, e ein Ausdruck und τ ein Typ.
Das s beschreibt den Zustand und n die Ebene, auf der sich der Compiler während
Typüberprüfung befindet.
8
Die Regel BRACKET drückt aus, dass ein Ausdruck in Quasi-Quotes immer den Typ ExpQ
hat (vgl. Kapitel 2.1) und dass der Ausdruck innerhalb der Quasi-Quotes auch geprüft wird,
jedoch auf einer Ebene höher (n+1) und im Zustand B.
Die Regeln ESCB und ESCS behandeln Ausdrücke, auf die ein "Splice"-Operator angewendet
wird. ESCB erklärt, wie ein "Splice"-Ausdruck überprüft wird. Innerhalb einer Quasi
Quotation muss lediglich geprüft werden, ob der Ausdruck, auf den der "Splice"-Operator
angewendet wird, vom Typ ExpQ ist. Das sagt noch nichts aus über den Typ des Ausdrucks,
zu dem der "Splice" ausgewertet wird. Der ausgewertete Ausdruck wird später mit dem
gesamten Ausdruck innerhalb der Quasi Quotation überprüft. Genau dies behandelt die Regel
ESCS, und zwar einen "Splice" im Zustand C und Ebene 0 zu überprüfen.
Die Umgebung Γ sammelt zusätzliche Informationen über Variablen und Funktionen
(Lambda-Abstraktionen) in der Form (x : (σ,m)), wobei x der Bezeichner der Variablen oder
Funktion ist , σ deren Typ und m die Ebene, in der sie gebunden ist.
Die Regeln LAM und VAR benutzen diese Informationen. In der Regel Var wird z.B.
getestet, ob die Ebene, in der eine Variable verwendet wird, höher ist, als die Ebene in der sie
angelegt wird.
Abbildung 2: Typisierungsregeln für Ausdrücke in Template Haskell
9
3.2 Deklarationen
Die Typisierungsregeln für Deklarationen sind in Abbildung 3 zu sehen. Sie haben die
konventionelle Form:
Abbildung 3: Typisierungsregeln für Deklarationen in Template Haskell
Wiederum ist hier Γ die Umgebung, in der die Deklaration geprüft wird. Γ' ist die kleinste
Umgebung, die die Typen der Variablen beinhaltet, die von der Deklaration gebunden
werden. Uns interessiert vor allem die Regel SPLICE, die, ähnlich wie die Regel ESCS, erst
den Ausdruck innerhalb des "Splice" prüft, ihn dann ausführt und dann die Deklarationen, die
er erzeugt, prüft. Es ist darauf zu achten, dass der "Splice"-Operator für Deklarationen nur im
Zustand C und Ebene 0 erlaubt ist.
An den Typisierungsregeln und dem Diagramm kann man einige Einschränkungen erkennen,
denen Template Haskell unterliegt:
•
Quasi Quotations dürfen nicht geschachtelt werden.
•
Der "Splice"-Operator darf auf Deklarationen nur auf höchster Ebene angewendet
werden (top-level declarations).
Das Generieren von mehreren Deklarationen in einer Gruppe wirft ein weiteres Problem auf.
Falls in einem Modul mehrere "Splices" vorkommen, so ist nicht klar, in welcher Reihenfolge
sie eingefügt werden. Die Typüberprüfung wird bei einer Gruppe von Deklarationen [d1, ... ,
dn] wie folgt durchgeführt:
[d1, ... , da] Splice ea [da+1, ... , db] Splice eb ... Splice ez [dz+1, ... , dn]
10
Es wird eine gewöhnliche Abhängigkeitsanalyse durchgeführt, gefolgt von einer
Typüberprüfung in der ersten Gruppe. In der resultierenden neuen Umgebung wird nun der
erste "Splice" auf seine Typen überprüft und eingefügt. Das Gesamtergebnis wird noch einer
Typüberprüfung unterzogen und es wird mit der nächsten Deklarationsgruppe fortgefahren.
Diese Vorgehensweise implementiert die Regel SPLICE (vgl. Abbildung 3).
4 Beispiele und Erläuterungen
4.1 Quasi Quotation vs Syntax-Generator Funktionen
Template Haskell Programme, die innerhalb von Quasi Quotations stehen, repräsentieren
Berechnungen von gewöhnlichen algebraischen Datenstrukturen, die Haskell Programme
erzeugen. Die Quasi Quotation Notation (siehe Kapitel 2.1) ist komfortabel und übersichtlich
für den Programmierer, jedoch stößt dieser Mechanismus schnell an seine Grenzen. Es gibt in
Haskell vordefinierte Funktionen fst :: (a, b) -> a und snd :: (a, b) -> b die für
2-Tupel die erste bzw. zweite Komponente ausgeben. Es wäre sehr mühsam für alle weiteren
n-Tupel (Tripel, Quadrupel,...) diese Funktionen per Hand zu schreiben. Wir wollen Funktion,
die uns diese, in Abhängigkeit ihrer Parameter zur Compile-Zeit erzeugt.
sel :: Int -> Int -> ExpQ
sel i n = [| \x -> case x of ...|]
Wie können wir die Patternabfrage innerhalb der Quasi Quotation schreiben? Das Konstrukt
ist zu unflexibel, da die Struktur des Patterns von einem Parameter abhängt, muss der Code
algorithmisch während der Compilierung erzeugt werden. Wir müssen die benötigte Struktur
direkt mit den expliziten Konstruktoren für Patterns und Ausdrücke erzeugen:
sel :: Int -> Int -> Exp
sel i n = LamE [VarP "x"] (CaseE (VarE "x") [alt])
where alt :: Match
alt = simpleMatch pat rhs
pat :: Pat
pat = TupP (map VarP as)
rhs :: Exp
rhs = VarE (as !! (i-1))
as :: [String]
as = ["a"++show i | i <- [1..n]]
Die Methoden können frei miteinander kombiniert werden. Ein wenig intuitiver ist die
folgende Version:
11
sel i n = [| \x -> $( return (CaseE (VarE "x") [alt])) |]
where ...
Hier kann man gut erkennen warum die Quasi Quotations für den Programmierer bequem
sind: Man sieht, was man bekommt. Sie bieten allerdings noch einen weiteren Vorteil, der im
folgenden Abschnitt besprochen wird.
4.2 Scoping
Eines der Kernprobleme von Template Haskell ist das versehentlich falsche Binden von
Variablen. Der Konstruktor VarE bekommt einen String übergeben und wandelt ihn in eine
Variable vom Typ Exp auf Objektebene um. Wenn sich nun der Geltungsbereich dieser
Variable mit Parametern gleichen Namens überschneidet, kann es zu Fehlern kommen, die für
den Programmierer schwer vorhersehbar sind. Betrachten wir die Funktion cross2a:
cross2a :: ExpQ -> ExpQ -> ExpQ
cross2a f g = [| \(x,y) -> ($f x, $g y) |]
Beim dem Aufruf von cross2a (VarE "x") (VarE "y") könnten die Ausdrücke (VarE x)
und (VarE y) versehentlich von den lokalen Objektvariablen in der Quasi Quotation gebunden
werden. Dies ist aber nicht der Fall, weil die Quasi Quotation die Objektvariablen
selbstständig umbenennt. Wir erhalten bei dem obigen Aufruf folgenden Ausdruck:
\(x0, y1) -> (x x0, y y1)
Leider unterstützen die Syntax-Generator Funktionen die automatische Generierung neuer
Namen nicht, d.h. der Programmierer muss dafür sorgen, dass Variablen eventuell umbenannt
werden. Hierfür steht die Funktion gensym :: String -> Q String zur Verfügung, die
neue Namen für Variablen liefert:
cross2b :: Exp -> Exp -> ExpQ
cross2b f g =
do
{ x <- gensym "x"
; y <- gensym "y"
; ft <- f
; gt <- g
;return LamE [TupP [VarP "x", VarP "y"]]
(TupE [AppE ft (VarE "x"), AppE gt (VarE "y")]))
Wir
können
dieses
Problem
auch
umgehen,
indem
wir
die
monadischen
Datentypkonstruktoren der Syntax-Generator Funktionen verwenden. Sie sind der monadische
Gegenpart der algebraischen Datentypkonstruktoren.
Die Quasi Quotations sind sehr bequem für den Programmierer und sie verstehen sowohl die
Typisierung als auch die Scoping Eigenschaften von Haskell. Genauer gesagt: Der
lexikalische Gültigkeitsbereich (lexical scope) jeder Variable bezüglich ihres Auftretens im
12
Quellprogramm vor jeder Expansion ist auch nach allen Expansionen unverändert. Damit es
nicht zu unbeabsichtigten Bindungen kommt, müssen die Quasi Quotations Variablen
umbenennen (vgl. Bsp. cross2a). Es besteht zusätzlich die Möglichkeit, dass Konflikte mit
Variablen auftreten, die außerhalb von Quasi Quotes gebunden sind.
module GS ( genSwap ) where
module SU where
swap (a,b) = (b,a)
import GS ( genSwap )
genSwap x = [| swap x |]
swap = True
swapUse = $(genSwap (4,5))
$(genSwap (4,5)) kann in diesem Beispiel nicht zu swap (4,5) expandiert werden, da das
swap des Splices von der booleschen Konstante des Moduls SU gebunden wird. Wir können
hier auf zwei verschiedene Arten vorgehen. Entweder wir deklarieren die Funktion swap in
genSwap lokal in einer where-Klausel, oder wir verwenden den Originalnamen (GS:swap
(4,5)). Da swap nicht importiert wird, kann man hier keinen qualifizierten Namen
(GS.swap) verwenden, was ebenfalls einen Konflikt im Namensraum des Moduls GS
hervorrufen würde. Originalnamen (GS:swap) dagegen sind eine Erweiterung zu Haskell, die
Template
Haskell
verwendet,
um
static
scoping
auch
für
die
Meta-
programmierungserweiterungen implementieren zu können. Originalnamen sind Teil der
Coderepräsentation, die sich eindeutig auf eine top-level Variable bezieht, die in
Gültigkeitsbereichen verdeckt sind und verwendet werden sollen.
Die Fähigkeit den Wert einer Variablen zur Compile-Zeit in generierten Code einzufügen,
nennt man cross-stage persistence. Probleme tauchen dabei ebenfalls für verschachtelte
Variablen auf, was eine andere Behandlung erfordert als bei top-level Variablen. Die Variable
x ist frei in [| swap x |] und hat keine top-level Bindung im Modul GS. Während der
Compilierung ist lediglich der Typ von x bekannt und deshalb kann x kein Originalname
gegeben werden. Bei dieser Art von Variablen geht es darum, beliebige Werte in Code
umzuwandeln, d.h. bei der Auswertung von $(genSwap (4,5)) muss der Wert des Tupels (4,5)
in eine Datenstruktur vom Typ Exp umgewandelt werden.
T:swap (4,5)
⇒ App (VarE "T:swap") (TupE [LitE (IntPrimL 4), LitE (IntPrimL 5)])
Dies geschieht über die Funktion lift, aus der Typ-Klasse Lift.
class Lift t where
lift :: t -> ExpQ
instance Lift Int where
lift = litE . IntegerL . fromIntegral
Die Instanzen der Klasse Lift erklären, wie die verschiedenen Typen der Klasse in den Typ Q
Exp "gehoben" werden sollen.
13
genSwap :: (Int,Int) -> ExpQ
genSwap x = do
{ t <- lift x
; return (AppE (VarE "T:swap") t) }
Somit sind freie Variablen einer top-level Quasi Quotation statisch abgeschlossen. Sie
brauchen in der Applikationsumgebung nicht verfügbar sein, oder können sogar durch gleiche
Namen verdeckt sein.
4.3 Eigenschaften der Quotation Monade
Die Quotation Monade übernimmt das Umbenennen der Variablen für den Programmierer.
Die Namensgebung folgt einem einfachen Muster:
•
der Typname eines monadischen Datentyps setzt sich aus dem Namen des
entsprechenden algebraischen Typnamen und einem Großbuchstaben (E für
Expression und P für Pattern) zusammen.
•
die
Namen
der
monadischen
Datentypkonstruktoren
beginnen
mit
einem
Kleinbuchstaben, die der algebraischen mit einem Großbuchstaben.
Als Beispiel seien hier die beiden Konstruktoren für die Lambda Abstraktion angegeben:
LamE :: [Pat] -> Exp -> Exp
-- { \ p1 p2 -> e }
lamE :: [Pat] -> ExpQ -> ExpQ
Man beachte, dass die Argumente von LamE lediglich Datentypen sind, wogegen die
Argumente von lamE Berechnungen sind.
lamE ps e = liftM (LamE ps) e
Für Patterns (Pat) gibt es keinen entsprechenden monadischen Typ. Dies liegt daran, dass sich
der Gültigkeitsbereich der Patterns über den ganzen Rumpf der Lambda Abstraktion erstreckt
und es deshalb keinen Grund gibt, einen neuen Namen für sie zu generieren.
Die Quotation Monade wird auch bei der Reification verwendet. Das Sprachkonstrukt der
Reification gibt ein Ergebnis als Quotation Monade zurück. typeStruct gibt eine
Berechnung vom Typ Q Dec zurück, die die interne Darstellung des GHC bezüglich des
Datentyps T liefert:
data T = A Int | B String
typeStructT :: Q Dec
typeStructT = reifyDecl T
Die Berechnung von typeStructT ergibt folgende Ausgabe:
Data [] "M:T" []
[Constr "TH_Bsp:A" [(NonStrict,Tcon (TconName "GHC.Base:Int"))],
Constr "M:B" [(NonStrict,Tcon (TconName "GHC.Base:String"))]]
[]
14
Das M vor dem Namen des Datentyps ist der Modulname, in dem der Datentyp deklariert ist.
Der Datentyp Dec aus dem Modul THSyntax hat für Datentypdeklarationen die folgende
Form:
data Dec = …
|DataD Cxt String [String]
-- { data Cxt x => T x = A x | B (T x)
[Con] [String]
--
deriving (Z,W)}
|…
Reification kann beim Debugging sehr nützlich sein. Das Konstrukt reifyLocn gibt die Stelle
seines Aufrufes innerhalb der Quelldatei in einen Q String zurück. Die Funktion assert führt
eine Überprüfung durch und bricht gegebenenfalls mit einer Fehlermeldung ab:
assert :: ExpQ
-- Bool -> a -> a
assert = [| \b r ->
if b then r else
(error ("Assertion failed at " ++ &reifyLocn |]
Die Funktion assert kann fehlerhafte Zustände erkennen und teilt durch reifyLocn dem
Benutzer mit, wo der Fehler abgefangen wurde. Hierbei ist es wichtig, das reifyLocn die
Position seines "Splices" nicht etwa die seiner Definition.
Es besteht die Möglichkeit, dass ein Meta-Programm fehlschlägt, weil es unachtsam
verwendet wird. Solche Fehler liegen weniger am Programmierer als am Benutzer.
Auf Grund der Quotation Monade kann der Programmierer solche Benutzerfehler abfangen
und den Fehler rückmelden. Betrachten wir erneut die Funktion sel. Es würde keinen Sinn
ergeben diese Funktion auf negative Parameter, etwa $(sel -1 3)anzuwenden. Wir benutzen
den monadischen Standard-Operator fail:
sel :: Int -> Int -> ExpQ
sel i n
|(i <= 0 || n <= 0) || (i >= n) = fail "Args are not valid to sel"
| otherwise = sel i n = lamE [varP "x"]…
Beliebige Input/Output Fähigkeiten für Meta-Programme können wir ebenfalls über die
Monade erzielen.
qIO :: IO a -> Q a
Bei solchen I/O Funktionen ist allerdings Vorsicht geboten, da ein Programm bei Missbrauch
dieser Funktionen beliebige Dateien löschen könnte.
Oft möchte man ein generiertes Programm nicht direkt compilieren, sondern in einer Datei
speichern. Gerade für einen guten Lerneffekt ist es von Vorteil, den Code, den man erzeugt
hat, ansehen zu können. Zu diesem Zweck bieten die Bibliotheken, die Exp, Dec, u.a. zu
Instanzen der Klasse Show machen. Dadurch können wir den im monadischen Gerüst
berechneten Code ausgeben lassen. Zum Beispiel erhält man bei der Ausführung von
15
main = do { e <- runQ (cross2b) ; putStr (show e)}
folgende Ausgabe:
LamE [TupP [VarP "x", VarP "y"]]
(TupE [AppE f (VarE "x"), AppE g (VarE "y")])
Die Quotation Monade besteht aus der IO Monade, die mit einer Umgebung Env erweitert ist.
newtype Q a = Q (Env -> IO a)
Die Umgebung beinhaltet folgende Informationen:
•
Eine veränderliche Speicherstelle, die der Generierung neuer Namen dient.
•
Die Ortsbestimmung eines (top-level) Splices, der eine Auswertung aufgerufen hat
(z.B. für reifyLocn).
•
Die Symboltabelle des Compilers, um reifyDecl, reifyFixity und reifyType zu
unterstützen.
•
Kommandozeilen-Optionen für reifyOpt.
•
5 Template Haskell in der Anwendung
5.1 Expandieren von Deklarationen des FFI
Um eine externe, fremde Bibliothek in Haskell zu importieren und nutzen zu können, gibt es
das FFI (foreign function interface). Für einen Import muss man einige Anweisungen in
verschiedene Dateien schreiben. Durch die Verwendung von Template Haskell ist es möglich,
mit Hilfe der Syntax-Generatoren abstrakte Syntaxbäume dieser Importdeklarationen zu
konstruieren. Diese Deklarationen der FFI foreign imports können zur Compile-Zeit in die
Haskellmodule expandiert werden. Innerhalb des Splices können wir eine Liste von
Bezeichnern angeben und bekommen die entsprechenden Importanweisungen zur CompileZeit geliefert. Im folgenden Beispielen aus [2] werden Graphikzeichen aus einer C Bibliothek
importiert.
$(
let fs = ["acs_block","acs_hline","acs_ulcorner"]
imp f = Foreign (
Import CCall Unsafe ("wrap.h "++ f) f
(Tapp (Tcon (TconName "IO")) (Tcon (TconName "ChType")))
)
in return $(map imp fs)
)
Das ist aber noch nicht alles, denn man kann in der Quotation Monade (vgl. Kapitel 4.3)
beliebige IO-Aktionen mit der Funktion qIO ausführen, die C Quell- und Headerdateien
16
als Strings erzeugen, sie in Dateien schreiben und sogar den gcc innerhalb des Splices
aufrufen:
$(
let fs = ["","",""]
imp f = Foreign (
Import CCall Unsafe ("wrap.h "++ f) f
(Tapp (Tcon (TconName "IO")) (Tcon (TconName "ChType")))
)
h f = "chtype " ++ f ++ "(void);\n"
c f = "chtype " ++ f ++ "(void){\n"
++ "
return " ++ map toUpper f ++ ";\n
++ "}\n"
c_header = "#include \"wrap.h\"\n"
h_header = "#include <curses.h>\n"
in do
qIO $(writeFile "wrap.h" $ h_header ++ concatMap h fs)
qIO $(writeFile "wrap.c" $ c_header ++ concatMap c fs)
qIO $(system "gcc -Wall -pedantic -c wrap.c -o wrap.o")
return $(map imp fs)
)
Die Funktion h erstellt die Strings für die Funktionsprototypen der C Headerdateien. Die
Funktion c erstellt die Strings für C wrapper-Funktionen, die jede importierte Konstante in
eine Funktion wandeln.
Der Vorteil an diesem Ansatz mit Template Haskell ist es, dass Compilierung in einem Schritt
erfolgt. Aus diesem Grund braucht man sich nicht um temporäre Dateien oder den
Präprozessor zu kümmern, wo es zu Konflikten kommen kann.
5.2 Optimierung durch "Unrolling"
Das "Unrolling" rekursiver Funktionen ist eine Technik zur Verbesserung der Leistung
rekursiver Berechnungen. "Unrolling" reduziert den Kontrollflussaufwand eines Programms
durch die Produktion von Code, der seltener die Abbruchbedingung einer Schleife überprüft.
Das Ziel ist es, dem Programmierer eine Funktion zur Verfügung zu stellen, die die Definition
einer Funktion als Argument erhält und eine äquivalente, aber "abgerollte", Funktion
zurückliefert. Im folgenden Beispiel wird die Definition eines Mandelbrot-Visualisierers
verwendet, der innerhalb eines "Splices" automatisch zur Compile-Zeit durch "Unrolling"
optimiert wird. Hier wird die Quasi Quotation für Deklarationen verwendet, die einen
abstrakten Syntaxbaum der Funktionsdeklarationen vom Typ Q [Dec] erzeugt.
type Iterations = Int
type T = Double
type C = Complex T
17
type Colour = (Int, Int, Int)
#ifdef TEMPLATE_HASKELL
$( do [typ, func] <- [d| {
#endif
do_mb :: T -> Iterations -> C -> C -> Colour;
do_mb k i z xy
| i > 255 = (0, 0, 0)
| otherwise = if (realPart z´)^2
+ (imgPart z´)^2 > k^2
then (0, 0, i)
else do_mb k (i+10) z´ xy
where z´ = z^2 +xy;
#ifdef TEMPLATE_HASKELL
} |]
let func´= unroll 30 1 (Integer 0) func
return [ typ, func´ ]
)
#endif
Die eigentliche Berechnung des Visualisierers ist recht einfach und wird für jeden Punkt eines
Bildes aufgerufen. Die #ifdef-Bereiche ermöglichen eine dynamische Fallunterscheidung, je
nachdem, ob Template Haskell unterstützt wird, oder nicht. Die Funktion do_mb wird anfangs
immer im Argument i mit Null aufgerufen und braucht nie mehr als 30 rekursive Aufrufe, um
zu terminieren. Der Wert 30 wird der Funktion unroll übergeben und begrenzt die tiefe der
"Auffaltung".
Das Ergebnis der Auswertung ist eine Folge von verschachtelten bedingten Ausdrücken:
do_mb :: T -> Iterations -> C -> C -> Colour;
do_mb k 0 z xy
= let z1 = z^2 + xy in
if (realPart z1)^2 + (imgPart z1)^2 > k^2
then (0, 0, 0)
else let z2 = z1^2 +xy in
if ...
...
else
let z26 = z25^2 +xy in
if (realPart z26)^2 + (imgPart z26)^2 > k^2
then (0, 0, 250)
else (0, 0, 255)
do_mb k i z xy
| i > 255 = (0, 0, 0)
18
| otherwise = if (realPart z´)^2
+ (imgPart z´)^2 > k^2
then (0, 0, i)
else do_mb k (i+10) z´ xy
where z´ = z^2 +xy;
Die Details zur Funktionsweise des Codes würden den Rahmen dieser Arbeit sprengen,
wichtig ist, dass die rekursiven Aufrufe durch Kopien des Funktionsrumpfes ersetzt werden.
So wurden erstaunliche Effizienzgewinne erzielt, die bei einer Verlängerung der Compile-Zeit
von 17 auf 29 Sekunden die Laufzeit von über einer Stunde auf fünf Minuten reduzierte.
Interessierte seien hier auf die Arbeiten [2] und [5] verwiesen.
Kapitel 6 Fazit
Der Ansatz zur Compile-Zeit Meta-Programmierung mit Template Haskell ist seit Oktober
2002 in stetiger Entwicklung und repräsentiert eine nicht abgeschlossene Arbeit. Jedoch
haben sich die Erweiterungen schon mehrfach als sehr nützlich erwiesen. In naher Zukunft
werden wohl noch offene Designfragen geklärt und weitere Funktionalität hinzugefügt.
Das Kernproblem, das nicht so leicht zu lösen sein wird, ist das der Unterstützung von Typund Striktheitsinformationen auf der Metaebene, die dem Programmierer für Applikationen
nicht zur Verfügung stehen. Dadurch können Sicherheitsbedingungen für Transformationen
auf abstrakten Syntaxbäumen nicht immer geprüft werden. Hier könnte die Einführung einer
zusätzlichen Typdokumentation hilfreich sein, die einem Ausdruck vom Typ Exp Q in Form
eines Parameters angehängt werden könnte.
19
Literatur- und Quellenverzeichnis
[1]
Sheard T., Peyton Jones, S.: Template Meta-programming for Haskell , to Haskell
Workshop 2002.
[2]
Lynagh, I.: Template Haskell: A Report From The Field, Unpublished.
[3]
Sheard T., Peyton Jones, S.: Notes on Template Haskell Version 2, 7. November 2003.
[4]
GHC User's Guide: http://www.haskell.org/ghc/docs/latest/html/users_guide/templatehaskell.html, Januar 2004.
[5]
Lynagh, Ian: Unrolling and Simplifying Expressions with Template Haskell,
web.comlab.ox.ac.uk/oucl/work/ian.lynagh/Fraskell/Template-Haskell-Utils.ps
20
Anhang A: Algebraische Datentyprepräsentation von Haskell
data Exp
= VarE String
-- { x }
| ConE String
-- data T1 = C1 t1 t2; p = {C1} e1 e2
| LitE Lit
-- { 5 or 'c'}
| AppE Exp Exp
-- { f x }
| InfixE (Maybe Exp) Exp (Maybe Exp) -- {x + y} or {(x+)} or {(+ x)} or {(+)}
-- It's a bit gruesome to use an Exp as the operator, but how else can we distinguish
-- constructors from non-constructors? Maybe there should be a var-or-con type?
-- Or maybe we should leave it to the String itself?
| LamE [Pat] Exp
-- { \ p1 p2 -> e }
| TupE [Exp]
-- { (e1,e2) }
| CondE Exp Exp Exp
-- { if e1 then e2 else e3 }
| LetE [Dec] Exp
-- { let x=e1; y=e2 in e3 }
| CaseE Exp [Match]
-- { case e of m1; m2 }
| DoE [Stmt]
-- { do { p <- e1; e2 } }
| CompE [Stmt]
-- { [ (x,y) | x <- xs, y <- ys ] }
| ArithSeqE Range
-- { [ 1 ,2 .. 10 ] }
| ListE [ Exp ]
-- { [1,2,3] }
| SigE Exp Type
-- e :: t
| RecConE String [FieldExp]
-- { T { x = y, z = w } }
| RecUpdE Exp [FieldExp]
-- { (f x) { z = w } }
deriving( Show, Eq )
data Dec
= FunD String [Clause]
| ValD Pat Body [Dec]
| DataD Cxt String [String]
[Con] [String]
| NewtypeD Cxt String [String]
Con [String]
| TySynD String [String] Type
| ClassD Cxt String [String] [Dec]
| InstanceD Cxt Type [Dec]
| SigD String Type
| ForeignD Foreign
deriving( Show, Eq )
data Type = ForallT [String] Cxt Type
| VarT String
| ConT String
| TupleT Int
| ArrowT
| ListT
| AppT Type Type
deriving( Show, Eq )
data Lit = CharL Char
| StringL String
| IntegerL Integer
| RationalL Rational
IntPrimL Integer
| FloatPrimL Rational
| DoublePrimL Rational
deriving( Show, Eq )
-- { f p1 p2 = b where decs }
-- { p = b where decs }
-- { data Cxt x => T x = A x | B (T x)
-- deriving (Z,W)}
-- { newtype Cxt x => T x = A (B x)
-- deriving (Z,W)}
-- { type T x = (x,x) }
-- { class Eq a => Ord a where ds }
-- { instance Show w => Show [w] where ds }
-- { length :: [a] -> Int }
-- forall <vars>. <ctxt> -> <type>
-- a
-- T
-- (,), (,,), etc.
-- ->
-- []
-- T a b
-- Used for overloaded and non-overloadedliterals.
-- We don't have a good way to represent non-- overloaded literals at the moment. Maybe that
-- doesn't matter?
-- Ditto
data Pat = LitP Lit
-- { 5 or 'c' }
| VarP String
-- { x }
| TupP [Pat]
-- { (p1,p2) }
| ConP String [Pat]
-- data T1 = C1 t1 t2; {C1 p1 p1} = e
| TildeP Pat
-- { ~p }
| AsP String Pat
-- { x @ p }
| WildP
-- { _ }
| RecP String [FieldPat]
-- f (Pt { pointx = x }) = g x
| ListP [ Pat ]
-- { [1,2,3] }
deriving( Show, Eq )
Weiter Datentypen aus THSyntax: data Foreign, data Callconv, data Safety, data Strict, data Con, data Module.
Anhang B: Monadische Syntax-Operatoren
-- The quotation monad as IO
fieldPat = (,)
newtype Q a = Q (IO a)
runQ :: Q a -> IO a
runQ (Q x) = x
type ExpQ = Q Exp
type DecQ = Q Dec
type ConQ = Q Con
type TypeQ = Q Type
type CxtQ = Q Cxt
type MatchQ = Q Match
type ClauseQ = Q Clause
type BodyQ = Q Body
type StmtQ = Q Stmt
type RangeQ = Q Rang
instance Monad Q where
return x
= Q (return x)
(Q m) >>= k = Q (m >>= \r -> unQ (k r))
fail s
= Q (fail s)
instance MonadIO Q where
liftIO = qIO
-- Lowercase pattern syntax functions
qIO :: IO a -> Q a
qIO io = Q io
intPrimL :: Integer -> Lit
intPrimL = IntPrimL
floatPrimL :: Rational -> Lit
floatPrimL = FloatPrimL
doublePrimL :: Rational -> Lit
doublePrimL = DoublePrimL
integerL :: Integer -> Lit
integerL = IntegerL
charL
:: Char -> Lit
charL
= CharL
stringL :: String -> Lit
stringL = StringL
rationalL :: Rational -> Lit
rationalL = RationalL
runQ :: Q a -> IO a
runQ (Q io) = io
gensym :: String -> Q String
gensym s = Q
( do { n <- readIORef counter
; writeIORef counter (n+1)
; return(s++"'"++(show n)) })
class Lift t where
lift :: t -> ExpQ
instance Lift Integer where
lift = litE . IntegerL
litP :: Lit -> Pat
litP = LitP
varP :: String -> Pat
varP = VarP
tupP :: [Pat] -> Pat
tupP = TupP
conP :: String -> [Pat] -> Pat
conP = ConP
tildeP :: Pat -> Pat
tildeP = TildeP
asP :: String -> Pat -> Pat
asP = AsP
wildP :: Pat
wildP = WildP
recP :: String -> [FieldPat] -> Pat
recP = RecP
instance Lift Int where
lift = litE . IntegerL . fromIntegral
instance Lift Char where
lift = litE . CharL
instance Lift Bool where
lift True = conE "GHC.Base:True"
lift False = conE "GHC.Base:False"
instance Lift a => Lift [a] where
lift xs = listE (map lift xs)
-- Combinator based types
fieldPat :: String -> Pat -> (String, Pat)
22
listP :: [Pat] -> Pat
listP = ListP
--
Exp
global :: String -> ExpQ
global s = return (VarE s)
varE :: String -> ExpQ
varE s = return (VarE s)
conE :: String -> ExpQ
conE s = return (ConE s)
litE :: Lit -> ExpQ
litE c = return (LitE c)
appE :: ExpQ -> ExpQ -> ExpQ
appE x y = do { a <- x; b <- y; return (AppE a b)}
infixE :: Maybe ExpQ -> ExpQ -> Maybe ExpQ -> ExpQ
infixE (Just x) s (Just y) = do { a <- x; s' <- s; b <- y; return (InfixE (Just a) s' (Just b))}
infixE Nothing s (Just y) = do { s' <- s; b <- y; return (InfixE Nothing s' (Just b))}
infixE (Just x) s Nothing = do { a <- x; s' <- s; return (InfixE (Just a) s' Nothing)}
infixE Nothing s Nothing = do { s' <- s; return (InfixE Nothing s' Nothing) }
infixApp :: ExpQ -> ExpQ -> ExpQ -> ExpQ
infixApp x y z = infixE (Just x) y (Just z)
sectionL :: ExpQ -> ExpQ -> ExpQ
sectionL x y = infixE (Just x) y Nothing
sectionR :: ExpQ -> ExpQ -> ExpQ
sectionR x y = infixE Nothing x (Just y)
lamE :: [Pat] -> ExpQ -> ExpQ
lamE ps e = liftM (LamE ps) e
lam1E :: Pat -> ExpQ -> ExpQ
lam1E p e = lamE [p] e
-- Single-arg lambda
tupE :: [ExpQ] -> ExpQ
tupE es = do { es1 <- sequence es; return (TupE es1)}
condE :: ExpQ -> ExpQ -> ExpQ -> ExpQ
condE x y z = do { a <- x; b <- y; c <- z; return (CondE a b c)}
letE :: [DecQ] -> ExpQ -> ExpQ
letE ds e = do { ds2 <- sequence ds; e2 <- e; return (LetE ds2 e2) }
caseE :: ExpQ -> [MatchQ] -> ExpQ
caseE e ms = do { e1 <- e; ms1 <- sequence ms; return (CaseE e1 ms1) }
doE :: [StmtQ] -> ExpQ
doE ss = do { ss1 <- sequence ss; return (DoE ss1) }
compE :: [StmtQ] -> ExpQ
compE ss = do { ss1 <- sequence ss; return (CompE ss1) } …
Weiter Hilfsfunktionen, Deklarationen, komplizierte Literale, implizite Parameter, u.a. wurden hier ausgelassen.
23