Download (1405Kb)

8.1. DATENREGELN 171
Das obige Programm spezifiziert keinesfalls den intendierten Test auf 0. Die Funktion isZero ist
noch nicht einmal eine Funktion über den ganzen Zahlen! Aus den Regeln folgt beispielsweise
Succ(Zero) ∼ isZero(Zero) ∼ isZero(Succ(Pred(Zero))) ∼ Zero,
und allgemein, daß alle Konstruktorgrundterme semantisch gleich sind. Das Programm ist nicht
konsistent, d.h. durch die Programmregeln werden Konstruktorterme semantisch gleichgesetzt, die
in dem durch die Datenregeln spezifizierten Basisdatentypen nicht semantisch gleich sind. Die Forderung
der Konsistenz ist auf dem Gebiet der algebraischen Spezifikationen wohlbekannt ([Gut77],
[Gut&Hor78], 3.2 in [Der&Jou90], [Wir90]), aber diese Eigenschaft ist für allgemeine Termersetzungssysteme
unentscheidbar (vgl. [Gut&Hor78]).
Sinnvoll, je nach Form der zugelassenen Datenregeln allerdings noch nicht hinreichend für die Konsistenz,
ist mit Sicherheit eine Anpassung der Eindeutigkeitsbedingung der Programmregeln (vgl. Def.
3.2, S. 38): Wenn zwei linke Programmregelseiten bezüglich der durch die Datenregeln erzeugten
Kongruenz unifizierbar sind, sollten auch die zugehörigen rechten Programmregelseiten bezüglich
dieser Kongruenz unifizierbar sein (für Unifikation bezüglich einer Kongruenz siehe [Der&Jou90],
[Jou&Kir91]). Das obige Beispiel 8.3 erfüllt diese Bedingung nicht. Die Unifizierbarkeit ist jedoch
selbst für durch konfluente, terminierende Termersetzungssysteme gegebene Kongruenzen nur semientscheidbar
(das Problem ist leicht auf Hilberts zehntes Problem der Lösbarkeit diophantischer
Gleichungen reduzierbar; siehe 6.3 in [Der&Jou90], auch 6. in [Huet&Op80]).
Für unsere Programme mit Pattern und Programme mit Hilfsfunktionen folgt die Konsistenz übrigens
direkt aus der Konfluenz. Diese ist bei der Verwendung von Datenregeln aber auch im allgemeinen
nicht mehr gegeben, so auch in Beispiel 8.3 nicht, obwohl die Datenregeln und die Programmregeln
jeweils für sich konfluent sind. Da die Konfluenz beliebiger Termersetzungssysteme
unentscheidbar ist, sie aber für operationelle Semantiken im allgemeinen benötigt wird, stellt dies
ein weiteres Problem dar.
Nach all diesen, mehr theoretische Aspekte betreffenden Nachteilen bringen wir schließlich noch
einen ganz pragmatischen Einwand vor: Das folgende Beispiel zeigt eine korrekte, konsistente Spezifikation
des Tests auf 0.
Beispiel 8.4 Datenregeln und Test auf 0 für ganz Zahlen, II
Die Datenregeln seien die gleichen wie in Beispiel 8.2.
isZero(x) → h(Zero,Zero,x)
h(x,y,Pred(z)) → h(x,Succ(y),z)
h(x,y,Succ(z)) → h(Succ(x),y,z)
h(Succ(x),Succ(y),Zero) → h(x,y,Zero)
h(Succ(x),Zero,Zero) → Zero
h(Zero,Succ(x),Zero) → Zero
h(Zero,Zero,Zero) → Succ(Zero)
Prinzip des Algorithmus:hzählt die im dritten Argument auftretendenSucc’s und Pred’s im ersten
respektive zweiten Argument. ✷
Zur Wahrung der Konsistenz ist diese äußerst umständliche und komplizierte Spezifikation nötig!
Die Funktionen müssen beliebige Konstruktorterme als Argumente ” korrekt verarbeiten“. Die dadurch
gegebene korrekte Spezifikation des nicht-freien Datentyps ist für die Praxis jedoch nur von
geringem Interesse.