08.10.2013 Aufrufe

Download (1405Kb)

Download (1405Kb)

Download (1405Kb)

MEHR ANZEIGEN
WENIGER ANZEIGEN

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:

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!