Download (1405Kb)

Die Bedeutung der Basisdatentypen wird in der Theorie der Programmschemata [Ind94] besonders
deutlich, die Schemata von Programmen unabhängig von konkreten Basisdatentypen — dort
Interpretationen genannt — betrachtet.
Funktionale Programmiersprachen besitzen üblicherweise einige Standardbasisdatentypen, beispielsweise
ganze Zahlen (Integer), Fließkommazahlen, Zeichen (Character), logische Werte (Boolean)
und Listen. Um auch Bäume und Matrizen direkt repräsentieren zu können, ermöglichen
moderne funktionale Programmiersprachen wie Miranda und Haskell dem Programmierer, neue,
eigene Basisdatentypen zu definieren: die sogenannten algebraischen Datentypen. Ein algebraischer
Datentyp der natürlichen Zahlen läßt sich folgendermaßen in Miranda definieren:
nat ::= Zero | Succ(nat)
Zero und Succ heißen Konstruktoren, und Konstruktorterme (Zero,Succ(Zero), . . .) bilden den
Träger des algebraischen Datentyps. Der Mechanismus des Patternmatchings ermöglicht nun die
einfache und intuitive Definition von Operationen über dem algebraischen Datentyp.
add(x,Zero) = x
add(x,Succ(y)) = Succ(add(x,y))
mult(x,Zero) = Zero
mult(x,Succ(y)) = add(x,mult(x,y))
Die Konstruktoren repräsentieren die Basisoperationen des algebraischen Datentyps, und das Patternmatching
verbindet zusätzlich eine Testoperation mit einer Komponentenselektion.
Algebraische Datentypen stellen ein äußerst mächtiges Konzept dar, da sie unter anderem die Definition
von Aufzählungstypen, markierten Vereinigungen von Typen und kartesischen Produkten
von Typen ermöglichen. Wie schon das obige Beispiel verdeutlicht, sind selbst die Standardbasisdatentypen
als algebraische Datentypen definierbar (auf Probleme mit den ganzen und Fließkommazahlen
gehen wir später noch ein). Dies rechtfertigt, im weiteren funktionale Programmiersprachen
zu betrachten, die nur algebraische Datentypen besitzen. Die Standardbasisdatentypen lassen sich
schlicht als effizientere Realisierungen entsprechender algebraischer Datentypen auffassen. In dieser
Arbeit untersuchen wir, wie sich für derartige konstruktorbasierte funktionale Programmiersprachen
sinnvoll Semantiken definieren lassen, ähnlich wie dies in [Vui74b] für Funktionsschemata
getan wurde.
Funktionale Programmiersprachen zeichnen sich durch die Möglichkeit aus, daß Funktionen höherer
Ordnung, sogenannte Funktionale, spezifizierbar sind. Wird der λ-Kalkül oder werden Kombinatorsysteme
als Grundlage funktionaler Programme verwendet, so ergeben sich Funktionale praktisch
automatisch. Sie sind jedoch kein notwendiger Bestandteil einer funktionalen Programmiersprache.
Auch bei einem Verzicht auf Funktionale besitzt man noch eine vollwertige (bezüglich der
natürlichen Zahlen mit Sicherheit universelle) Programmiersprache. Es existieren auch reale funktionale
Programmiersprachen wie beispielsweise Sisal, die nur die Spezifikation von Funktionen erster
Ordnung ermöglichen. Auch rekursive Funktionsschemata sind im allgemeinen erster Ordnung
([Ind94]). Die hier zu untersuchende semantische Beschreibung auf Konstruktoren basierender Basisdatentypen
und des Patternmatchings ist unabhängig von dem Vorhandensein von Funktionalen.
Semantiken funktionaler Programmiersprachen höherer Ordnung sind mathematisch aufwendiger,
da aufgrund der Funktionale ein spezifizierter Datentyp keine einfache Algebra mehr sein kann.
Daher beschränken wir uns auf konstruktorbasierte funktionale Programme erster Ordnung.
5