Types and Programming Languages: Einführung Typen SWT Seminar WS 05/06 Linda Schmuhl Manuel Aldana Dozenten: Florian Kammüller, Matthias Vösgen

Gliederung Typisierung arithmetische Ausdrücke Einfach getypter lambda-Kalkül Typlöschung Zusammenfassung/Fragen

Typisierung arithmetische Ausdrücke

Vorteile der Typisierung Fehlererkennung Flüchtigkeitsfehler (vergessener Cast) Konzeptuelle Fehler (komplexe Fallunterscheidungen) Wartung Änderungen in den Datenstrukturen führen zu „erwünschten“ Inkonsistenzen Dokumentation insbesondere in verwendeten Interfaces Effizienz weniger Checks zur Laufzeit notwendig Vor allem in Entwicklungsphase Bestimmte Art von Fehlern Je eher, desto besser Effekt ist abhängig von Güte des Typsystems, das verwendet wird sowie Umfang der verwendeten Datenstrukturen Abstraktionen - weg von der Hardware Im folgenden soll anhand einer Beispielsprache gezeigt werden, wie die Vorteile der Typisierung von Sprachen genutzt werden können.

Syntax untypisierter arithmetischer Ausdrücke t ::= Terme true Konstante true false Konstante false if t then t else t Konditional 0 Konstante Null succ t Nachfolger pred t Vorgänger iszero t Null-Test Evaluation t -> t ’ if true then t2 else t3 -> t2 E-IF-TRUE if false then t2 else t3 -> t3 E-IF-FALSE t1 -> t1’ E-IF if t1 then t2 else t3 -> if t1’ then t2 else t3 t1 -> t1’ E-SUCC succ t1 -> succ t1’ pred 0 -> 0 E-PRED-ZERO pred (succ nv1) -> nv1 E-PRED-SUCC t1 -> t1’ E-PRED pred t1 -> pred t1’ iszero 0 -> true E-ISZERO-ZERO iszero (succ nv1) -> false E-ISZERO-SUCC t1 -> t1’ E-ISZERO iszero t1 -> iszero t1’ v ::= Werte true true-Wert false false-Wert nv numerischer Wert nv ::= numerische Werte 0 Wert 0 succ nv Nachfolger-Wert Ausgangspunkt ist die bereits kennengelernte Sprache der arithmetischen Ausdrücke. Menge der Terme / Vokabular der Sprache auffallend: zusammengesetzte Terme beinhalten eine Metavariable, die durch einen beliebigen anderen Term ersetzt werden kann. Menge der Werte wie bekannt Inferenzregeln manche mit und ohne Prämissen Auch hier Metavariablen, die beliebige Terme repräsentieren Werden auf einen Term sukzessive die passenden Regeln angewendet, so endet die Evaluierung in einem Wert.

Probleme untypisierter Terme These: Evaluierung eines Terms führt immer zu einem Wert. iszero (if true then 0 else succ 0) succ if iszero (succ 0) then false else true Werden auf einen Term sukzessive die passenden Regeln angewendet, so endet die Evaluierung in einem Wert. Normalform kurz erklären Problem: Stuck state erst zur Laufzeit entdeckt Ziel: Fehler bereits zur Compile-Zeit entdecken und beheben können, nicht erst zur Laufzeit, dann vielleicht zu spät Dabei hilft die Typisierung! Stuck State: Term ist in Normalform, aber noch kein Wert erreicht

Idee der Typisierung Termen werden Klassen zugeordnet, die ihr Evaluierungsergebnis charakterisieren = Typen = Typisierungsrelation t : T „t ist vom Typ T“ Binäre Relation zwischen Termen und Typen Bedeutung: ohne Evaluierung ist klar, dass der entsprechende Term nach seiner Auswertung zu einem Wert des genannten Typs führt. Explizite vs. Implizite Typisierung Bedeutung: Es ist ohne Notwendigkeit einer Evaluierung ersichtlich, dass der Term zu einem Ergebnis dieses Typs führt.

Erweiterung der Syntax arithmetischer Ausdrücke t ::= Terme true Konstante true false Konstante false if t then t else t Konditional 0 Konstante Null succ t Nachfolger pred t Vorgänger iszero t Null-Test T ::= Typen Bool Typ der booleschen Ausdrücke Nat Typ der natürlichen Zahlen v ::= Werte true true-Wert false false-Wert nv numerischer Wert nv ::= … Neu: Menge von Typen, die den Termen zugeordnet werden können

Erweiterung der Syntax arithmetischer Ausdrücke II Evaluationsregeln t -> t ’ if true then t2 else t3 -> t2 E-IF-TRUE if false then t2 else t3 -> t3 E-IF-FALSE … Typisierungsregeln true : Bool T-TRUE false : Bool T-FALSE t1 : Bool t2 : T t3 : T T-IF if t1 then t2 else t3 : T 0 : Nat T-ZERO t1 : Nat T-SUCC succ t1 : Nat t1 : Nat T-PRED pred t1 : Nat t1 : Nat T-ISZERO iszero t1 : Bool Zusätzlich zu Evaluierungsregeln: Typisierungsregeln Regeln ohne und mit Prämissen Axiome = direkte Zuordnung der Konstanten zu Typen übrige Regeln ordnen den nicht-konstanten Termen Typen zu, sofern Sub-Terme von einem gegebenen Typ sind. Bedeutsam Terme innerhalb der zusammengesetzten Terme nicht mehr beliebig sind Einhalten der Prämisse garantiert Typ des Evaluierungsergebnisses

Wohlgeformter Term Definition: Ein Term t ist typisierbar oder wohlgeformt (well-typed), wenn es unter Berücksichtigung der Typisierungsregeln einen Typen T gibt, sodass gilt: t : T nicht erst zur Laufzeit Konsequenz: Für jeden Term kann vor der Evaluierung, also zur Compile-Zeit, entschieden werden, ob er wohlgeformt ist und wenn ja, welchem Typen er zugeordnet werden kann.

Ableitungsbäume aus den Typinformationen seiner Subterme kann eindeutig auf den Typen des Terms selbst geschlossen werden genau ein Ableitungsbaum pro wohlgeformtem Term Wie kann man sich diesen Typcheck ohne Evaluierung vorstellen?

Typcheck: Positives Beispiel (Ableitungsbaum siehe Tafel) iszero (if true then 0 else succ 0)

Typcheck: Negatives Beispiel (Ableitungsbaum siehe Tafel) succ if iszero (succ 0) then false else true

Sicherheit von Typsystemen Garantie, dass wohlgeformte Terme während ihrer Evaluation niemals in einen Stuck State führen Eigenschaft der Wohlgeformtheit reicht als Aussage, dass dieser Term zur Laufzeit keinen Typ-Fehler erzeugen wird nicht-wohlgeformte Terme sind potentielle Laufzeit-Fehler, können aber per Typcheck vorher berichtigt werden Sicherheit eines Typsystems kann gezeigt werden In 2 Stufen und zwar über 2 Eigenschaften Sicherheit = Progress + Preservation

Progress Ein wohlgeformter Term ist niemals in einem Stuck State. Term t Wert t -> t‘

Preservation Ein wohlgeformter Term bleibt auch nach Anwendung einer Evaluierungsregel wohlgeformt. t : T und t → t′, so gilt t′ : T

Einfach getypter Lambda-Kalkül

Motivation Typen für arithmetische Ausdrücke kennengelernt Ziel: Typcheck verhindert Stuck State zur Laufzeit Stuck-State: Term=Normalform + Wert Gleiches soll für den lambda Kalkül eingeführt werden

Vorgehensweise Einführung Typcheck für lambda-Kalkulus Vorgehensweise wie bei arithm. Ausdrücken: Term Syntax Typ-Regeln Abstrakte Ebene verwendet befolgt Term Typcheck checkt Konkrete Ebene

Wiederholung (kurz) Lambda Kalkül stellen Funktionen dar, die Eingänge als Variablen enthalten und miteinander komponiert werden können Drei einfache Konstrukte: Variablen Abstraktion Applikation

Syntax Erweiterung: Funktions-Typ Lambda-Ausdrücke repräsentieren Funktionen Idee Einführung einfacher Funktions-Typ: Funktions-Typ der Beispiel-Terme: Einfacher Funktions-Typ nicht mächtig genug…

Funktions-Typ Typ-Definition (wie wird Typ zusammengestzt): Typ-Relation (wie wird einem Term ein Typ zugeordnet): Typ-Urteil (wie werden gebundenen Variablen Typen zugeordnet): Menge Typ-Urteil auf Term Erweiterung Typ-Urteil

Typ-Regeln Typchecker verwendet Typ-Regeln Pro lambda-Konstrukt eine Typ-Regel Variablen Typ-Regel: Abstraktion Typ-Regel: Applikation Typ-Regel:

Typcheck Beispiel Beispiele eines Typchecks auf lambda-Ausdrücke Typdefinition Typ-Regeln

Typcheck Ergebnis 1) 2) ist wohlgeformt ist nicht wohlgeformt Beispiele (Ableitungsbaum siehe Tafel): 1) ist wohlgeformt 2) ist nicht wohlgeformt

Typlöschung

Löschen von Typinformationen Typ-Informationen sind für Evaluierung irrelevant Typ-Informationen stellen Overhead dar und können gelöscht werden Typ-Information über Typ-Rekonstruktion wieder herstellbar

Zusammenfassung Vorgestellt wurde statische Typisierung von arithmetischen und lambda-Ausdrücken Term-Typisierung realisiert über Typ-Syntax Term-Typcheck realisiert über Typ-Regeln Typisierung + Typcheck verhindert Fehlerklasse „Stuck-State“ Typsicherheit-Beweis über Eigenschaften Progress und Preservation

Fragen an Euch :) Kann ein Term typsicher sein? Warum sollten Normalformen aus Werten bestehen? Positive/Negative Erfahrung mit nicht-statischer Typisierung (meist Skriptsprachen)?