Download (1405Kb)

74 KAPITEL 5. DIE ς-SEMANTIKEN
Änderungen läßt sich die cbn-Transformation auch auf die cbv-Interpretationen und umgekehrt die
cbv-Transformation auf die cbn-Interpretationen anwenden.
Die auf erstere Art entstehende Semantik ist gar nicht so ungewöhnlich. In der Literatur über Fixpunktsemantiken
von Funktionsschemata ([Vui74], [Manna74], [Nivat75], [Dow&Se76], [Loe&Sie87],
[Ind93]) werden ” cbn-Semantiken“ mit nicht-strikten Funktionen über flach geordneten Basisdatentypen
(discrete domains) betrachtet (nur [Ber&Lévy77] und [Cou90] betrachten auch nicht-flach
geordnete Basisdatentypen). Somit wird die ” unnatürliche“, ” erzwungene“ Striktheit der Funktionen
in der Transformation vermieden; aufgrund der flachen Halbordnung des Basisdatentyps bleibt
die gesamte Theorie der Fixpunktsemantik jedoch so einfach wie unsere cbv-Fixpunktsemantik.
Die Semantik, die auf die zweite Art entsteht, ist sogar in der funktionalen Programmiersprache
Hope 1 realisiert worden (Kapitel 4 in [Fie&Har88]). Diese kombiniert nicht-strikte Konstruktoren
mit darüber definierten strikten Funktionen. Auf diese Weise besitzt Hope die mächtigen Ausdrucksmöglichkeiten
unendlicher Datenstrukturen, kann aber den in Implementationen effizienteren
cbv-Auswertungsmechanismus teilweise verwenden.
Durch die möglichen Kombinationen von Interpretationen und Transformationen erhalten wir insgesamt
vier verschiedene Semantiken. Dies hat den unerfreulichen Aspekt, daß wir auch vier verschiedene
Reduktionssemantiken (noch zwei) definieren und viermal die Übereinstimmung von Fixpunktund
Reduktionssemantik beweisen müssen. Zwischen den vier Semantiken bestehen zwar enge Beziehungen
und daher Ähnlichkeiten, aber allgemeine Aussagen über genau diese vier lassen sich
schwer beweisen.
Da außerdem die Hilfsoperationen zum Basisdatentyp gehören, sollte sich ihre Striktheit bzw. Nicht-
Striktheit nach den Konstruktor- und nicht nach den Funktionsoperationen richten. Allerdings sind
ihre Striktheiten aufgrund ihrer speziellen Reduktionsregeln sowieso in allen vier Semantiken gleich.
Die Lösung des Problems besteht in der schlichten Idee einer weiteren Verallgemeinerung. Wir
führen einen neuen Parameter ς ein, der für jede Argumentstelle jedes Operationssymbols angibt,
ob die Operation an dieser Argumentstelle strikt sein soll. Auf diese Weise erhalten wir zwar eine
beliebig große Anzahl von Semantiken (in Abhängigkeit von der Programmsignatur), aber wir
können diese auf ziemlich einfache Weise einheitlich behandeln. Wir werden sehen, daß gerade
diese Verallgemeinerung zu einem tieferen Verständnis — auch der schon untersuchten cbv- und
cbn-Semantiken — führt.
Die Striktheit bzw. Nicht-Striktheit der Konstruktoroperationen wird direkt durch den neuen Parameter
ς bestimmt. Dagegen kann die Striktheit von Funktions- und Hilfsoperationen schon allein
durch das Programm festgelegt sein (siehe dazu Beispiel 3.2, S. 39; die Operation von and ist auch
in der cbn-Semantik strikt). Bei prinzipiell möglicher Nicht-Striktheit von Funktions- oder Hilfsoperationen
soll der Parameter ς die Striktheit jedoch erzwingen können. Dies führt uns zu der
Bezeichung ” erzwungene Striktheit“.
Definition 5.1 Erzwungene Striktheit
Eine Abbildung
ς :
n∈IN
Σn→IB n
heißt erzwungene Striktheit zur Signatur Σ. Sie ordnet jedem Signatursymbol g ∈ Σ seine
erzwungene Striktheit ς(g) zu.
Sei ς eine erzwungene Striktheit, g (n) ∈ Σn und t1, . . .,t n ∈ T∞ Σ,⊥ . g heißt genau dann erzwungen
1 Es existieren neben der Standardimplementierung allerdings auch Implementierungen von Hope, die mit dem
reinen cbn-Auswertungsmechanismus arbeiten.