Download (1405Kb)

50 KAPITEL 4. DIE STANDARDSEMANTIKEN
Übereinstimmung werden in [Manna74], [Vui74], [Vui74b], [Nivat75], [Dow&Se76], [Ber&Lévy77],
[ADJ77], [Gue81], [Loe&Sie87], [Cou90], [Ind93] und [Ind94] untersucht.
Da unsere Programme mit Pattern aufgrund der Pattern auf den linken Regelseiten keine Funktionsschemata
sind, greifen wir bei den Reduktionssemantiken, wir wir schon gesehen haben,
hauptsächlich auf den Kalkül der Termersetzungssysteme zurück. Schon [O’Do77] verwendet Termersetzungssysteme
als Grundlage operationeller Semantiken funktionaler Programmiersprachen.
Aus den beiden Blickwinkeln — der Funktionsschemata und der Termersetzungssysteme — ergeben
sich widersprüchliche Einordnungen der Hilfsfunktionen der Programme mit Hilfsfunktionen.
Aus Sicht der Funktionsschemata sind sie — da unabhängig vom konkreten Programm — Teil
des Basisdatentyps und damit den Konstruktoren gleichgestellt. Andererseits existieren für sie Termersetzungsregeln
genauso wie für die übrigen Funktionen, und beide werden bei der Reduktion
gleich behandelt. Da wir der Einfachheit halber meistens Programme mit Hilfsfunktionen als spezielle
Programme mit Pattern auffassen, neigen wir mehr dem letzteren Standpunkt zu. Wir wollen
trotzdem nicht vergessen, daß Hilfsoperationen eine Sonderstellung zwischen den Konstruktoroperationen
und den Funktionsoperationen einnehmen.
Schließlich wollen wir noch auf die Beziehung zu algebraischen Spezifikationen hinweisen, für die
[Wir90] eine ausführliche Übersicht darstellt, und die in [Broy&Wir82], [Broy&Wir83], [Gut77],
[Gut&Hor78] und [Thiel84] behandelt werden. Unsere Programme sind ausführbare Spezifikationen.
Daher übernehmen wir von algebraischen Spezifikationen den Standpunkt, ein Programm als
die Spezifikation eines Datentyps, einer Algebra aufzufassen. Der Kalkül der Funktionsschemata
verwendet nämlich nur die Operation eines ausgezeichneten Funktionssymbols als Semantik, wie
wir schon in der Einleitung erwähnten. Die hierarchische Spezifikation eines Datentyps auf der
Grundlage eines anderen Basisdatentyps ist eines der Hauptanliegen der Theorie der algebraischen
Spezifikationen. In Kapitel 6 werden wir unsere Semantiken noch einmal vom Standpunkt der
algebraischen Spezifikationen betrachten und untersuchen.
Nach unseren Überlegungen zur Semantik unserer Programme in 3.3 sind wir jetzt auf der Suche
nach (invarianten) Grundtermsemantiken für unsere Programme, insbesondere solchen, die
auf (deterministischen) Reduktionsstrategien beruhen. Im Zusammenhang mit höheren Programmiersprachen
fällt oft der Begriff des Auswertungsmechanismus. Dieser beschreibt, wie in einer
höheren Programmiersprache die Parameterübergabe an Funktionen oder Prozeduren erfolgt. Für
funktionale Programmiersprachen sind die beiden unterschiedlichen Auswertungsmechanismen
call-by-value (cbv) und call-by-name (cbn) bekannt, und sie stehen in engem Zusammenhang
mit bestimmten Reduktionsstrategien.
Der cbv-Auswertungsmechanismus wertet erst die Argumente einer Funktion vollständig aus, bevor
die Funktion selber ausgeführt wird. Dies ist der Auswertungsmechanismus der meisten imperativen
Programmiersprachen. Dagegen erfolgt bei dem cbn-Auswertungsmechanismus der Funktionsaufruf
direkt; die unausgewerteten Argumente werden in den Funktionskörper hineinkopiert.
Die Argumente werden erst ausgewertet, wenn sie wirklich benötigt werden. Das folgende Beispiel
verdeutlicht die beiden Auswertungsmechanismen.
Beispiel 4.1 Call-by-value und call-by-name
Call-by-value Auswertung:
head(liste1) −−→
P
liste1 → []:liste1
head(x:xs) → x
head([] : liste1) −−→
P
head([] : [] : liste1) −−→
P
. . .