Beispiel: Anreicherung um rek. Definition

Append =enrich List withfunctions . + . : list × list → list;axioms[] + l = l;(a + l) + l’ = a + (l + l’);end enrich

Append ist hierarchiepersistent und eindeutig(+ ist überladen: sowohl Element vor Liste hängen (rot und schwarz),als auch 2 Listen zusammenhängen (blau))

146

Beispiel: Anreicherung um rek. Prädikat (FU)

Sorted =enrich List withpredicates sorted : listaxiomsordered([]),ordered(a + []),ordered(a + b + l) ↔ a < b ∧ ordered(b + l)end enrich

Ordered ist hierarchiepersistent und eindeutig,

da die FU vollständig ist (jede Liste ist entweder = [], a+ [], a+ b+ l)

147

Strukturierte Spezifikationen:

Umbenennung und Parameter

148

Strukturierte Spezifikationen:Umbenennung

Umbenennung:

• benennt die Operationen einer Spezifikation um

• nützlich um 2 Kopien zu erhalten

• Syntax: rename <SPEC> by morphism<renaming1>;...<renamingn>;

end rename

• renaming = <sort/op/var> → <sort/op/var>;

• identische Umbenennungen weglassen(werden beim Ansehen der Spezifikation aber angezeigt)

• Nicht 2 Symbole auf dasselbe abbilden: injektiv umbenennen

• entweder alle Variablen oder keine umbenennen

149

Beispiel Umbenennung:Listen zu Stacks

rename List by morphismlist → stack;[] → empty;(: Typangabe f ur uberladenes Symbol :)+ :: (elem × list → list) → push;(: pop nicht mehr postfix, Schreibweise stattdessen pop(x) ,

default ist in/prae/postfix uebernehmen :).rest → pop prio 0;(: top soll nun praefix sein :).first → top .;(: eigentlich keine Stack-Operation,

nur um Overloading zu zeigen :)+ :: (list × list → list) → concat prio 0;x → st;y → st0;z → st1;end rename 150

Strukturierte Spezifikationen:Generische Spezifikation

Generische Spezifikation:

• Syntax: generic specificationparameter <SPEC>using <SPEC1>, ..., <SPECn>target

<signature><induction><axioms>

end generic specification

• wie Anreicherung (von <SPEC>, <SPEC1>, ..., <SPECn> ), nur wirdvon <SPEC>explizit gesagt, dass es sich um einen Parameter handelt

• Vereinigung und Anreicherung übernimmt den (oder die) Parameter derUnterspezifikationen

• Variante: generic data specification : wie data specification nur mit Parameter

151

Strukturierte Spezifikationen:Aktualisierung (1)

Aktualisierung:

• instanziert Parameter (oder einen Parameter) einer Spezifikation

• Beispiel: Listen beliebiger Elemente → Listen von Zahlen

• Syntax: actualize <SPEC> with <ASPEC1>,...,<ASPECn> by morphism<renaming1>;...<renamingn>;

end actualize

• renaming = <sort/op/var> → <sort/op/var>;

• Die Vereinigung von <ASPEC1>,...,<ASPECn>heisst aktuelle Spezifikation

• identische Umbenennungen weglassen

• entweder alle Variablen oder keine umbenennen

152

Strukturierte Spezifikationen:Aktualisierung (2)

Aktualisierung:

• Der Parameter muss in die aktuelle Spez. abgebildet werden

• Abbildung darf nicht-injektiv sein: pair(elem1 , elem2 ) → pair(nat ,nat)

• Der Nicht-Parameter-Teil darf nur injektiv,und disjunkt zur aktuellen Spez. umbenannt werden, z.B. list → natlist

• Die instanzierten Axiome des Parameters müssen Axiome in deraktuellen Spezifikation sein

• Verallgemeinerung instantiated specification :⋆ Axiome werden bewiesen⋆ mapping statt morphism erlaubt es,

eine Sorte auf ein Tupel von Sorten abzubilden⋆ (später bei ASMs)

153

Aktualisierung: Beispiel (1)

Order =specificationsorts elem;constants d : elem;predicates ≪ : elem × elem;variables a, b, c : elem;axioms¬ a ≪ a; a ≪ b ∧ b ≪ c → a ≪ c;¬ a ≪ d; (: d ist minimal :)end specification

List-Ord =generic data specificationparameter Orderusing Natlist = [] | . + . (. .first : elem; . .rest : list);size functions length : list → nat;end generic data specification

154

Aktualisierung: Beispiel (2)

NatList =actualize List-Ord with Natby morphismlist → natlist;elem → nat;≪ → <;d → 0;a → n; b → n0; c → n1;end actualize

Die instanzierten Axiome (u.a. ¬ n < 0) sind(modulo Umbenennung) in Nat vorhanden.

Die Listenoperationen (+, .rest etc.) werden nicht umbenannt(sie bekommen nur die neuen Sorten als Argumente)

155

Strukturierte Spezifikation:

Nichtfreie Datentypen

156

Nichtfreie Datentypen: der typische Fehler

Orderedlist =enrich List3 withpredicates

. < . : elem × elem ;ordered : list ;

axioms¬ a < a; a < b ∨ a = b ∨ b < a;a < b ∧ b < c → a < c;ordered([]); ordered(a + []);ordered(a + b + l) ↔ a < b ∧ ordered (b + l);

end enrich

NICHT ∀ l. ordered(l) addieren!!! Das wäre INKONSISTENT!!!

Allgemein: Ein generierter Datentyp enthält immer alle Konstruktorterme.Man kann nicht nachträglich welche ausschliessen. Man kann nur einennichtfreien Datentyp bilden, der Terme identifiziert

157

Spezifikation nichtfreier Datentypen

• Spezifikationen nichtfreier Datentypen werden sehr leicht inkonsistentoder uneindeutig

• Konstruiere nichtfreien Datentyp durch Zusammenfassung von denTermen, die die gleichen Elemente repräsentieren sollen, in Klassen

• Deshalb als erstes nach der Bestimmung der Konstruktoren:Definiere Gleichheit durch Extensionalitätsaxiom: x = y ↔ ϕ(x, y)

• Dann: die in ϕ definierten Operationen werden rekursiv definiert

• damit: monomorph: höchstens ein Datentyp spezifiziert

• Vorsicht: rek. Def. kann inkonsistent sein!

• Jetzt: Arrays, im Praktikum: Mengen (einfacher)

158

Beispiel: Arrayspezifikation, Teil 1

Array=specification

using Nat; Elem;sorts array;functions

mkar : nat × elem → array;. [ . , . ] : array × nat × elem → array;. [ . ] : array × nat → elem;# . : array → nat;

inductionarray generated by mkar, . [ . , . ];

variables d : elem; a, a’ : array;

159

Beispiel: Arrayspezifikation, Teil 2

Festlegungen:

• Konstruktor mkar(n, d) bekommt Initialelement d(Alternative: unspezifizierte Initialisierung)

• Für m ≥ # a ist Selektion a[m] unspezifiziert

• Für m ≥ # a ist Modifikation Identität: a[m,d] = a.

axiomsa = a’ ↔ # a = # a’ ∧ ∀ n. n < # a → a[n] = a’[n];

# mkar(n,d) = n; # a[m , d] = # a;

m < n → mkar(n,d)[m] = d;

m < # a → a[m , d][m] = d; n 6= m → a[m , d][n] = a[n];end specification

160

Inkonsistente rekursive Definition

• Annahmen:⋆ Mengen von nat. Zahlen definiert⋆ Die Mengen sind von ∅ und insert generiert⋆ Für Mengen gilt: insert(a,insert(a,∅)) = insert(a,∅)

• Rekursive Definition:sum(∅) = 0,sum(insert(a, s)) = a + sum(s)

• Inkonsistent, da aus insert(1,insert(1,∅))) = insert(1,∅) folgt:2 = sum(insert(1,insert(1,∅))) = sum(insert(1,∅)) = 1

• Korrekte Definition:sum(∅) = 0,¬ a ∈ s→ sum(insert(a, s)) = a + sum(s)(im Fall a ∈ s ist insert(a, s) = s)

• Operation sum muss mit der Definition der Gleichheit auf Mengen,i.e. dem Extensionalitätsaxiom verträglich sein!

161

Anforderungen an nichtfreie Datentypen

• Semantische Überlegungen zur Spezifikation nichtfreier Datentypen:⋆ Es gibt den Datentyp ⇒ Konsistenz (wenn Axiome für den

intendierten Datentyp gelten)⋆ Die im Extensionalitätsaxiom durch ϕ beschriebene Relation muss

wenigstens Äquivalenzrelation sein:− Reflexivität: ϕ (a, a)− Kommutativität: ϕ (a, b) → ϕ (b, a)− Transitivität: ϕ (a, b) ∧ ϕ (b, c) → ϕ (a, c)

• Für gleiche Konstruktorterme t1, t2 muss Operation f dasselbe liefern:ϕ (t1,t2) → f(t1) = f(t2)⇒ Beweisverpflichtungen; genaueres: siehe Modulversuch!

• Äquivalenzrel. + Verträglichkeit = Kongruenz

162

Korrekte Spez. der geordneten Listen (1)

Orderedlist = specificationsorts elem; ordlist;constants [] : ordlist;functions

. + . : elem × ordlist → ordlist ;min : ordlist → elem ;butmin : ordlist → ordlist ;

predicates

. < . : elem × elem ;variables

a, b, c : elem;l, l ′ : ordlist;

inductionordlist generated by [], +;

163

Korrekte Spez. der geordneten Listen (2)

axioms¬ a < a; a < b ∨ a = b ∨ b < a;a < b ∧ b < c → a < c;

l = l′ ↔ l = [] ∧ l’ = []∨ l 6= [] ∧ l’ 6= []

∧ min(l) = min(l′)∧ butmin(l) = butmin(l′);

min(a + []) = a;a < b → min(a + b + l) = min(a + l);¬ a < b → min(a + b + l) = min(b + l);

butmin(a + []) = [];a < b → butmin(a + b + l) = b + butmin(a + l);¬ a < b → butmin(a + b + l) = a + butmin(b + l);

end specification

164

Noethersche Induktion

165

Noethersche Induktion (1)

Definition (noethersche Relationen)Sei ≪ ⊆ A×A. Die Relation ≪ heißt noethersch (oder wohlfundiert, engl.well-founded) wenn es keine unendlichen ≪-Ketten gibt:

. . .≪ a3 ≪ a2 ≪ a1 ≪ a0

Satz (Ordnungsprädikate)Ordnungsprädikate von Datendefinitionen sind noethersch in jedem Modellder Spezifikation.

166

Noethersche Induktion (2)

Satz (noethersche Induktion)Für noethersche Relationen ≪ gilt:Wenn für jedes a aus E(a′) für alle Elemente a′ ≪ a die Aussage E(a)gefolgert werden kann, so gilt E für alle Elemente:

(∀ a. (∀ a′. a′ ≪ a⇒ E(a′)) ⇒ E(a)) ⇒ ∀ b. E(b)

Definition (noethersche Induktionsregel)Sei y := free(Γ ⊢ ∆) \ {x} und ≪ noethersch. Induktion über x:

IND(≪)

∀ y.∀ x′. x′ ≪ x→ (∧

Γ →∨

∆)x′

x ,Γ ⊢ ∆

Γ ⊢ ∆

167

Noethersche Induktion (Beispiele)

Beispiel: Natürliche Zahlen

∀ n0. n0 < n→ ϕ(n0) ⊢ ϕ(n)

⊢ ∀ n. ϕ(n)

Beispiel: Listen

∀ l0. (l0 ≪ l) → ϕ(l0) ⊢ ϕ(l)

⊢ ∀ l. ϕ(l)

168

Noethersche Induktion (Beispielprädikate)

Größenordnung:Sei size : s→ nat . Dann ist ≪ noethersch mit

x≪ y :↔ size(x) < size(y).

Lexikalische Ordnung:Betrachte Spezifikation Pair2 von vorher. Seien <1 : elem1 × elem1 und <2 :elem2 × elem2 noethersch. Dann auch ≪ mit

mkpair(a, b) ≪ mkpair(a′, b′) :⇔ a <1 a′ ∨ (a = a′ ∧ b <2 b

′).

Untermengenordnung:Seien s, s′ zwei endliche Mengen (Spezifikation später). Dann ist

s ⊂ s′ ↔ s ⊆ s ∧ s 6= s′

noethersch, da s ⊂ s′ → card(s) < card(s′).

169