Download (1405Kb)

170 KAPITEL 8. NICHT-FREIE DATENTYPEN
DP,ς bzw. deren Basisdatentypen zu der Konstruktorsignatur C = {Zero (0) ,Succ (1) ,Pred (1) } kommt
dies überhaupt nicht zum Ausdruck, während nicht-freie Datentypen gerade dies ermöglichen
(sollen).
Derartige nicht-freie Datentypen betrachten wir in diesem Kapitel. Da wir dieses komplexe Gebiet
nur kurz anreißen wollen, verzichten wir ganz auf formale Definitionen und beschäftigen uns mit den
neu auftretenden Phänomenen in allgemeiner und intuitiver Weise. Auf die Darstellung der speziell
durch partielle und unendliche Datenstrukturen verursachten Probleme verzichten wir ganz, und
wir betrachten auch keine Hilfsfunktionen, sondern nur Abwandlungen unserer Programme mit
Pattern.
8.1 Datenregeln
Es liegt nahe, die semantische Gleichheit unterschiedlicher Konstruktorgrundterme durch Gleichungen
von Konstruktortermen zu spezifizieren. Der Basisdatentyp ist dann die Quotientenalgebra der
Konstruktorgrundtermalgebra modulo der durch diese Gleichungen bestimmten Kongruenz. Da
sich, wie wir schon in 7.1 bezüglich des initialen Modells eines Programms anmerkten, nicht auf
beliebigen Äquivalenzklassen rechnen läßt, verwenden wir anstelle von Gleichungen ein konfluentes,
terminierendes Termersetzungssystem. Damit sind dann die Konstruktornormalformen die
eindeutigen Repräsentanten der Datenelemente. Die Konstruktorsymbole zusammen mit den Regeln
dieses Termersetzungssystems, den Datenregeln, spezifizieren den nicht-freien Basisdatentyp.
Ein einen nicht-freien Basisdatentyp spezifizierendes Programm besteht damit aus Datenregeln und
Programmregeln.
Beispiel 8.2 Datenregeln für ganze Zahlen
Datenregeln:
Programmregeln für die Addition:
Succ(Pred(x)) → x
Pred(Succ(x)) → x
add(x,Zero) → x
add(x,Succ(y)) → Succ(add(x,y))
add(x,Pred(y)) → Pred(add(x,y))
Diese Spezifikationsmethode bringt aber mehrere Probleme mit sich.
Erstens ist es nicht entscheidbar, ob die Datenregeln tatsächlich ein konfluentes und terminierendes
Termersetzungssystem bilden. Wir haben jedoch gefordert, daß die syntaktische Korrektheit
eines Programms entscheidbar sein und jedem syntaktisch korrektem Programm eine Semantik
zugeordnet werden soll.
Das folgende Beispiel verdeutlicht ein zweites, fundamentales Problem.
Beispiel 8.3 Datenregeln und Test auf 0 für ganze Zahlen, I
Die Datenregeln seien die gleichen wie in Beispiel 8.2.
Programmregeln:
isZero(Zero) → Succ(Zero)
isZero(Succ(x)) → Zero
isZero(Pred(x)) → Zero
✷
✷