Download (1405Kb)
Download (1405Kb)
Download (1405Kb)
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Kapitel 3<br />
Die Programme<br />
Wir geben in 3.1 zwei Syntaxdefinitionen für konstruktorbasierte funktionale Programme erster<br />
Ordnung an. Hierbei setzen die ersteren Patternmatching zur Funktionsdefinition ein, während die<br />
letzteren explizite Test- und Dekompositionsfunktionen verwenden.<br />
Diese Programme sind spezielle Arten von beinahe orthogonalen Termersetzungssystemen, und<br />
daher können wir in 3.2 deren Theorie auf Programme übertragen. Insbesondere ist die Reduktionsrelation<br />
eines Programms konfluent.<br />
Somit sind Normalformen in Programmen eindeutig. Dies legt die Definition einer darauf basierenden<br />
operationellen Normalformsemantik nahe. Diese besitzt jedoch eine unschöne Eigenschaft:<br />
sie ist nicht invariant. Die Invarianz und weitere grundlegende, für formale Semantiken unserer<br />
Programme benötigte Begriffe werden in 3.3 definiert.<br />
3.1 Die abstrakte Syntax<br />
Anfangs haben wir festgestellt, daß eine Programmiersprache aus den zwei Komponenten Syntax<br />
und Semantik besteht. Wir definieren hier die Syntax zweier verschiedener konstruktorbasierter<br />
funktionaler Programmarten erster Ordnung. Später werden wir zu jeder Syntax mehrere verschiedene<br />
Semantiken angeben. Somit werden wir auch insgesamt nicht nur zwei, sondern weitaus mehr<br />
verschiedene Programmiersprachen erhalten.<br />
Wir geben die Syntax nicht durch kontextfreie Grammatiken — etwa in Backus-Naur-Form — an.<br />
Derartige Grammatiken enthalten viele irrelevante Details und beschreiben hauptsächlich das äußere<br />
Erscheinen eines Programms, wie es vom Programmierer gesehen wird. Beispielsweise legen sie<br />
fest, ob Funktionsdefinitionen durch Kommata, Semikola oder Punkte getrennt oder abgeschlossen<br />
werden, und welche arithmetischen Operatoren stärker binden (*) als andere (+). Dieser ” syntaktische<br />
Zucker“ ist für die Lesbarkeit eines Programms von Bedeutung, für die formale Manipulation<br />
von Programmen sind diese Details jedoch störend. Schon in 2.4 haben wir Terme rein durch ihre<br />
algebraischen Eigenschaften definiert. Entsprechend geben wir auch hier durch abstrakte Syntax<br />
die syntaktische Struktur von Programmen an (vgl. Kapitel 3 in [Meyer90], auch [ADJ77]).<br />
Wir wollen uns nun zuerst den Programmen zuwenden, die Patternmatching zur Funktionsspezifikation<br />
verwenden. Bereits in der Einleitung haben wir ein Beispiel für ein Programm mit Pattern<br />
gesehen: