Strukturierte Spezifikation: Freie Datentypen

Transkript

1 Strukturierte Spezifikation: Freie Datentypen 113

2 Wie spezifiziert man Datentypen? Vorgehen: Definiere benötigte Sorten Letzte Vorlesung: Datentypen auf Rechnern sind generiert Definiere Konstruktoren und Generiertheitsklauseln Definiere weitere Operationen und ihre Axiome Problem: Wie geeignete, richtige Axiome finden? Formal richtig : Sie sollten für den gewünschten Datentyp stimmen (keine Inkonsistenz!), und sollten ihn möglichst eindeutig charakterisieren. 114

3 Freie und nichtfreie Datentypen nat nat???? by???? by integer???? by set???? by set???? by stack???? by bintree???? by graph???? by list???? by 115

4 Freie und nichtfreie Datentypen Beobachtung: Manche Datentypen sind frei (erzeugt): Zwei verschiedene Konstruktorterme repräsentieren auch immer zwei verschiedene Elemente. nat 0, +1 nat 0,1,+ integer 0, +1, 1 set, ins set, {.}, stack empty, push bintree mkleaf, mkbranch graph, +node, +edge list [], + 115

5 Freie und nichtfreie Datentypen Beobachtung: Manche Datentypen sind frei (erzeugt): Zwei verschiedene Konstruktorterme repräsentieren auch immer zwei verschiedene Elemente. nat freely generated by 0, +1 nat generated by 0,1, = 0 integer generated by 0,+1, = 0 set generated by, ins ins(a,ins(a, )) = ins(a, ) set generated by, {.}, {a} {a} = {a} stack freely generated by empty, push bintree freely generated by mkleaf, mkbranch graph generated by, +node, +edge +node n +node n = +node n list freely generated by [], + 115

6 Axiome für freie Datentypen Beispiel: Konstante c, einstellige Funktion f, zweistellige Funktion g Verschiedenheit der Konstruktoren c, f und g: c f(x), f(x) g(y,z), c g(x,y) Injektivität der Konstruktoren: f(x) = f(y) x = y, g(x,y) = g(u,v) x = u y = v Satz: Die Spezifikation mit diesen Axiomen ist monomorph und konsistent, sie charakterisiert also genau einen Datentyp. KIV: Schreibe freely generated by, Axiome werden generiert. 116

7 Freie Erzeugtheitsklauseln Freie Erzeugtheitsklauseln A = S freely generated by C : A = S generated by C Für zwei verschiedene Terme t,t T s (C,X \ X s ) mit s S gibt es Variablenbelegungen v,v, so dass [[t]] A,v [[t ]] A,v Insbesondere sind Terme mit verschiedenen Konstruktoren immer verschieden. 117

8 Freie Datentypen (Beispiel 1) Beispiel 1: Wochentage Weekday1 = specification sorts weekday; constants Mon, Tue, Wed, Thu, Fri, Sat, Sun : weekday; induction weekday freely generated by Mon, Tue, Wed, Thu, Fri, Sat, Sun; variables w : weekday; end specification Generierte Axiome: Die Konstanten Mon, Tue, Wed,... sind paarweise verschieden: Mon Tue, Mon Wed, Mon Thu, Mon Fri,

9 Freie Datentypen (Beispiel 1) Induktionsregel für die Sorte weekday Γ Mon w Mon w... Γ Sun w Γ Sun w Beweis durch Fallunterscheidung nach dem Tag Verallgemeinerung: Aufzählungstypen 119

10 Freie Datentypen (Beispiel 2) Beispiel 2: Die natürlichen Zahlen Nat3 = specification sorts nat; constants 0 : nat; functions +1 : nat nat; variables n : nat; induction nat freely generated by 0, +1; end specification Neu: Axiome jetzt generiert. 120

11 Freie Datentypen (Beispiel 3) Beispiel 3: Paare Pair1 = specification sorts elem1; elem2; pair; functions mkpair : elem1 elem2 pair; induction pair freely generated by mkpair; variables a : elem1; b : elem2; p : pair; end specification Generiertes Axiom: mkpair(a 1,b 1 ) = mkpair(a 2,b 2 ) a 1 = a 2 b 1 = b 2 121

12 Freie Datentypen (Beispiel 3) Induktionsregel für die Sorte pair Γ mkpair(a,b) p mkpair(a,b) p Γ Expandiert Variable p zu mkpair(a, b) Verallgemeinerung: Tupel 122

13 Freie Datentypen (Beispiel 4) Beispiel 4: Listen List2 = specification sorts list, elem; functions [] : list;. +. : elem list list; variables a, b: elem; l, l 1, l 2 : list; induction list freely generated by [], +; end specification 123

14 Freie Datentypen (Beispiel 4) Generierte Axiome Spezifikation generiert: [] a + l, a + l 1 = b + l 2 a = b l 1 = l 2 Induktionsregel für die Sorte list y. Γ,Γ a+l l Γ a+l l Γ [] l [] l y = free(γ ) \ {l} 124

15 Data Specification (Motivation) Häufige Situation: Freie Erzeugbarkeit mit Konstruktoren c Selektoren, die aus c(x 1,...x n ) die x i selektieren Testprädikate ist mit Konstruktor c gebildet Ordnung: ist Unterterm von Größenfunktion: Anzahl nichtkonstanter Konstruktoren Eigenes Syntaxkonstrukt data specification vermeidet unnötige Schreibarbeit. 125

16 Data Specification (Beispiel 1) Beispiel 1: Wochentage Weekday2 = data specification weekday = Mon Tue Wed Thu Fri Sat Sun; variables w : weekday; end data specification 126

17 Data Specification (Beispiel 2) Beispiel 2: natürliche Zahlen Nat4 = data specification nat = (. 1 : nat); variables n : nat nat; order predicates. <. : nat nat; end data specification Neue Axiome: n +1 1 = n; (: 0 1 ist unspezifiziert :) n < n; m<n n<k m<k; n < 0; m < n +1 (m = n m < n) 127

18 Data Specification (Beispiel 3) Beispiel 3: Paare Pair2 = data specification using Elem1, Elem2; pair = mkpair (..1 : elem1;..2 : elem2 ) variables p : pair; end data specification Neue Axiome : mkpair(a,b).1 = a; mkpair(a,b).2 = b 128

19 Data Specification (Beispiel 3) Beispiel 4: Listen List3 = data specification using Nat, Elem; list =. +. (..first : elem;..rest : list) with consp [] with nilp; variables l : list; (: ist Unterterm für Listen = ist Endstück :) order predicates.. : list list; size functions length : list nat; end data specification 129

20 Selektoren als partielle Funktionen Problem: Was tun, wenn ein Selektor auf den falschen Summand angewandt wird? Hier: Was sind [].first und [].rest?.first und.rest sollten für [] garnicht definiert sein Partielle Funktionen In KIV: []. first und [].rest sind unspezifiziert (i. e. kein Axiom) Semantik: [].rest ist in jeder Algebra (Datenstruktur) irgendeine andere Liste Echte Implementierung muss irgendeine Liste zurückgeben Pragmatik: Formeln mit [].rest sollten nicht vorkommen. Wenn doch, muss die Sequenz ohne die Formeln beweisbar sein. Bem.: Alternativen sind möglich aber komplizierter (Fehlerelemente, echte Partialität, etc.) 130

21 Data Specification (Beispiel 3) Neue Axiome für List3: nilp([]); nilp(a + l); consp([]); consp(a + l); (a + l).first = a; (: kein Axiom für [].first :) (a + l).rest = l; (: kein Axiom für [].rest :) l []; l (a + l 1 ) l = l 1 l l 1 ; (: beweisbar, aber der Einfachheit halber generiert :) l l; l 1 l 2 l 2 l 3 l 1 l 3 ; length([]) = 0; length(a + l) = length(l) +1; 131

22 Data Specification allgemein Definition (Datendefinition) Eine Datendefinition D hat die Form (optionales in eckigen Klammern): s = c 1 (sel 1,1 : s 1,1 ;...;sel 1,n1 : s 1,n1 ) [with p 1 ]... c k (sel k,1 : s k,1 ;...;sel k,nk : s k,nk ) [with p k ]; [order predicate..;][size function sz;] Überladen: sel i,j = sel i,j erlaubt, falls s i,j = s i,j, ansonsten alle Operationen paarweise verschieden. 132

23 Eigenschaften von Data Specifications Satz: Alle Data Specifications sind immer konsistent. Sie sind immer monomorph bis auf unspezifizierte Selektoren. Intuition bei Listen ist also: Wir haben exakt den Datentyp der Listen beschrieben. Wir haben lediglich für die Realisierung auf einem Rechner offen gelassen, was für ein Element bzw. was für eine Liste [].first und [].rest zurückgeben. 133

24 Strukturierte Spezifikation: Anreicherung um nichtrekursive und rekursive Definitionen 134

25 Strukturierte Spezifikationen Motivation Spezifikationen werden sehr schnell sehr groß Strukturierung erforderlich 1. Übersichtlichkeit & Verständlichkeit 2. Wiederverwendung von Komponenten 3. Unabhängige Entwicklung von Komponenten 4. Strukturierung und Wiederverwendung von Beweisen 135

26 Strukturierte Spezifikationen in KIV KIV zeigt strukt. Spezifikationen als Spezifikationsgraph an In KIV enthält jeder Knoten neben der Spezifikation außerdem eine Theorembasis Die Theorembasis enthält eine Menge von Theoremen (Sequenzen) über der Gesamtsignatur Für jede Sequenz kann ein Beweis vorhanden sein, der zeigt, daß die Sequenz aus SP und anderen Theoremen folgt (keine zyklischen Abhängigkeiten) Theoreme aus darunterliegenden Spezifikation werden mit insert spec-lemma statt insert lemma angewandt KIV hat ein Korrektheitsmanagement, um Abhängigkeiten zwischen Beweisen zu verwalten 136

27 Strukturierte Spezifikationen: Vereinigung und Anreicherung Vereinigung Wirft Signaturen + Axiome zusammen Syntax: union specification <SPEC1> + <SPEC2> +... end union specification Zu vermeiden: Nichtdisjunkte Vereinigung (Gefahr der Inkonsistenz!) Anreicherung Addiert neue Signaturen + Axiome Syntax: enrich <SPEC1>, <SPEC2>,... with <signature> <induction> <axioms> end enrich Implizit: Ausgangsspezifikation der Anreicherung ist die Vereinigung von <SPEC1>, <SPEC2>,

28 Anreicherung: Vorgehen Neue Axiome hinzuzunehmen macht eine Spezifikation sehr schnell inkonsistent (siehe Versuch 3!) Gewünscht: Nur konsistenzerhaltende Anreicherungen Formaler Begriff: Konsistenzerhaltend = Hierarchiepersistent Neue Operationen sollten monomorphieerhaltend sein: Wenn genau ein Datentyp spezifiziert, sollte die Operation ebenfalls eindeutig festgelegt sein Formaler Begriff: Monomorphieerhaltend = Eindeutig Vorgehen: Anreicherung nur durch rekursive und nichtrekursive Definitionen für neue Operationen. Diese sind hierarchiepersistent und eindeutig. 138

29 Nichtrekursive Definitionen (Motivation) Grundidee: Definition als Abkürzung einer grossen Formel Prädikat: p(x) ϕ (p kommt in Formel ϕ nicht vor) Funktion: f(x) = t (f kommt im Term t nicht vor) 139

30 Beispiel: Anreicherung um nichtrek. Prädikat NatDiv = enrich Nat with predicates : nat nat; axioms m n k. k * m = n; end enrich Die Anreicherung NatDiv ist hierarchiepersistent und eindeutig 140

31 Beispiel: Anr um nichtrek. Prädikat (mit FU) NatPrime = enrich NatDiv with predicates prime : nat; axioms prime(0); prime(1); n 2 (prime(n) m. m n m = 1 m = n); end enrich Die Anreicherung NatPrime ist hierarchiepersistent und eindeutig (FU nach n = 0, n = 1, n 2 ist vollständig) 141

32 Beispiel: Anreicherung um nichtrek. Konstante Nat12 = enrich Nat with constants 1 : nat; 2 : nat; axioms 1 = 0 +1; 2 = ; end enrich Die Anreicherung Nat12 ist hierarchiepersistent und eindeutig (beachte: in KIV sind die Zahlen schon vordefiniert) 142

33 Weitere Beispiele für nichtrekursive Definitionen m n k. m + k = n m < n m n m n m > n n < m even(n) m. n = m + m odd(n) even(n) m < n min(m,n) = m, m < n min(m,n) = n x 0 abs(x) = x, x < 0 abs(x) = x last(l + (a + [])) = a (: unvollst. Def :) a l l,l. l + a + l = l isprefix(l,l ) l. l + l = l nodups(l) l 1,l 2,l 3,a. l = l 1 + a + l 2 + a + l 3 143

34 Nichtrekursive Definitionen allgemein Prädikat: p(x) ϕ (p kommt in Formel ϕ nicht vor) Funktion: f(x) = t (f kommt im Term t nicht vor) Prädikat mit 2 vollständigen Fällen: ε (q(x,y) ϕ 1 ), ε (q(x,y) ϕ 2 ) Funktionen mit 3 unvollständigen Fällen: ε δ f(x,y) = t 1, ε δ f(x,y) = t 2, ε δ f(x,y) = t 3 Satz: Die Hinzunahme einer neuen Operation (Funktion oder Prädikat) mit nichtrekursiver Definition ist immer hierarchiepersistent. Wenn die Fälle vollständig sind, ist die Erweiterung sogar eindeutig. 144

35 Rekursive Definitionen (Motivation) Datentypen bestehen aus (der Semantik von) Konstruktortermen Rekursive Definitionen geben Definition durch Reduktion auf kleinere Konstruktorterme Entsprechen einem rekursiven Programm, das den Term abläuft Length = enrich List with functions length : list nat; axioms length([]) = 0; length(a + l) = length(l) +1; end enrich Satz: Die Hinzunahme einer neuen Operation mit rekursiver Definition zu einem freien Datentyp ist immer hierarchiepersistent. Wenn die Fälle vollständig sind, ist die Erweiterung immer eindeutig. 145

36 Beispiel: Anreicherung um rek. Definition Append = enrich List with functions. +. : 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

37 Beispiel: Anreicherung um rek. Prädikat (FU) Sorted = enrich List with predicates sorted : list axioms ordered([]), 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

38 Strukturierte Spezifikationen: Umbenennung und Parameter 148

39 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

40 Beispiel Umbenennung: Listen zu Stacks rename List by morphism list stack; [] empty; (: Typangabe für überladenes 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

41 Strukturierte Spezifikationen: Generische Spezifikation Generische Spezifikation: Syntax: generic specification parameter <SPEC> using <SPEC1>,..., <SPECn> target <signature> <induction> <axioms> end generic specification Wie Anreicherung (von <SPEC>, <SPEC1>,..., <SPECn>), nur wird von <SPEC> explizit gesagt, dass es sich um einen Parameter handelt Vereinigung und Anreicherung übernimmt den (oder die) Parameter der Unterspezifikationen Variante: generic data specification: Wie data specification nur mit Parameter 151

42 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

43 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 Spezifikation umbenannt werden, z. B. list natlist Die instanzierten Axiome des Parameters müssen Axiome in der aktuellen Spezifikation sein Verallgemeinerung instantiated specification: Axiome werden bewiesen mapping statt morphism erlaubt es, eine Sorte auf ein Tupel von Sorten abzubilden 153

44 Aktualisierung: Beispiel (1) Order = specification sorts 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 specification parameter Order using Nat list = []. +. (..first : elem;..rest : list); size functions length : list nat; end generic data specification 154

45 Aktualisierung: Beispiel (2) NatList = actualize List-Ord with Nat by morphism list 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