Download Formal Modules (Abstract Data Types) and Object Oriented Programming.

Formal Modules (Abstract Data Types)
and object oriented programming
· Jason J. Hickey
· Cornell University
Outline
·
·
·
·
·
Programming motivation
Modularity
Very-dependent types
Related work
Grand Unified Type Theory (GUTT)
Scalable programming
· Large software systems
· CAD tools
· AT&T failure—incorrect syntax
· Loose specifications
· Verification is often secondary
· High-level programming
· Complex constructs
· Abstraction
· Logic
· “Specification”
· Comparison of two programs
· Fault tolerance?
Formal programming
·
·
·
·
·
·
Logical specifications
Functional programming
Automatic program extraction
Unified framework
Lack of modularity
versus:
· Fault tolerance
· Natural language
· Associative architectures
Guidelines for formal software design
Compromise
· Require more explicit specifications
· Use constructivism constructively
· Higher level types (specification for free)
· Higher level assertions
· Static (as well as runtime) verification
· Provide tools for modularity
· Abstraction of object properties
· Abstraction barriers to isolate implementations
· Allow feature extension for software re—use
· With formal domains, we hope to provide “natural” tools
Definitions
·
·
·
·
Abstract Data Type = Module specification = Class
Module implementation = Object
Object ∈ Class
A Class is primitive, or it is a collection of classes
· Usually there is some coherence
· An object is:
· A “value”
· A “method”
Modularity
(A real-life example)
· type Torso =
{ s:Spine, r:Rib list,
l:Leg list, b:BButton }
· type Spine =
{v: Vertebra list }
· type Vertebra =
Bone { properties of
vertebrae }
· type Rib =
Bone {properties of ribs }
· type Bone =
{ properties of bones }
7
Modularity
(A mathematical example)
Semi-group
is
×
×
×
×
×
×
×
×
car : Type
=: car → car → Prop
∀x: car .x = x
∀x, y: car .x = y ⇒ y = x
∀x, y, z: car .x = y ⇒ y = z ⇒ x = z
⊕: car → car → car
∀x, y, z: car .(x ⊕ y) ⊕ z = x ⊕ (y ⊕ z)
1: car
∀x: car .x ⊕ 1 = x
Group is Semi-group
× ∀x: car .∃y: car .x ⊕ y = 1
Modularity
A logic(al) example
Logic
Arithmetic
Algebra
Rationals
λ-calculus
Programming
Data structures
Set Theory
How are these concepts related?
·
·
·
·
·
Proposal: they are all identical
They can be implemented the same way
They have similar, if not exactly the same, informal semantics
Each is an instance of a qualified assertion
Great observation—what does it buy us?
· A formal concept of an “object”
· A formal relation between the logic and the object specification
· A reflection of modularity onto the semantics
· Representation coercions are the identity
How can we extend the formalism?
·
·
·
·
Implement a class as an extensible, dependent record type
Implement an object as a record
A class is a DAG of classes:
Each subclass:
· lists its dependencies
· extends the definition by one item
Primitive object
·
·
A collection of “parent” specifications
A (single) method extending the object
SG1 == Parents: [ ], Method: car : Type
SG2 == Parents: [SG1], Method: =: car → car → Prop
SG3 == Parents: [SG2], Method: ∀x: car .x = x
Semi-group
G1 == Parents: [Semi-Group], Method: ∀x: car .∃y: car .x ⊕ y = 1
Group
R1 == Parents: [Semi-Group; Group];
Common-Root: [car];
Method: ∀x: car .∃y: car .x ⊕ y = 1
Ring
Very dependent types
Dependent type x:D Æ R(x)
·
·
·
·
Range specification depends on argument
D is a type, and for any x ∈ D, R(x) is a type
f ∈ x:D → R if f is a function, and for x ∈ D, f(x) ∈ R(x)
Month functions: m:{1...12} → {1...DaysPerMonth(m)}
Person: Field
name
age
employer
salary
Type
String
N
Company
Z
l : Label → case l of
name
age
employer
salary
⇒
⇒
⇒
⇒
String
N
Company
Z
Very dependent types
Very dependent function type {f | x:D → R(x, f) }
Semi-group: Label
car
⊕
=
op–assoc

 ¯
¯
case l of



¯





 ¯¯
 car
⊕
f ¯¯l : Label →




¯
=



¯

 ¯

op–assoc
Type
Type
car → car → car
car → car → Prop
∀x, y, z: car .(x ⊕ y) ⊕ z = x ⊕ (y ⊕ z)
⇒
⇒
⇒
⇒
Type
f (car ) → f (car) → f (car )
f (car ) → f (car) → Prop
∀x, y, z: f (car) .(x f (⊕) y) f (⊕) z f (=)











Do we need a formal definition?
· Most/all formal object-oriented systems do not have a
proof-theoretic concept of an object specification
· Object mechanism is based on records
· Some dependent
· Most independent
· However, we have:
· Theoretical interest
· Practical interest in formal functors:
· Optimization
· Compilation
· Property extraction
Alternative semantics
· Is it necessary to provide a well-founded order
· The order can be determined from the range computation
· Is it necessary to require a well-founded order?
· The monotonically increasing functions on Z → Z
n ¯
o
¯
f ¯i: Z → {j: Z |j > f (i − 1)}
· Can we construct a type for partial functions?
n ¯
o
¯
f ¯i: D → if ↓ f (i) then R
Other very dependent types
Very dependent W-types
W(x:A; B[x])
a
a1
a2
W(a:A; b:B(a); C(a, b))
B[a]
aω
a,c(a1, a2, ..., aω)
a1
a2
B[a]
aω
Other very dependent types
Very dependent recursive types
· List of T : µ(X.Unit + X × T )
Dependent list of T : µ(X.Unit + x: X × T (x))
· May have no fixed point
· The meaning is clear:
· The type is its • unrolling
· Union of all unrollings
· We don't need an extension to the type theory—just one
ordinal i: ω × T i
· Or an indexed union
[
i∈ω
Ti
Class definitions
· A class is a theory
*C multiset_begin
*A T: Ui
*A car: Ui
*A inject: T ∅ car
*A ≈: car ∅ car ∅ car
*A ∀a, b: car. a ≈ b = b ≈ a car
•••
*C multiset_end
*C int_multiset_begin
*T T (Z)
*T car (T ∅ B)
•••
*C int_multiset_end
*C dec_multiset_begin
*A ∀a, b: car. a = b car + a ≠ b car
•••
*C dec_multiset_end
*C int_dec_multiset_begin
*T ∀a, b: car. a = b car + a ≠ b car
•••
*C int_dec_multiset_end
Construction by formation
· A class can be defined as a theory
· Axioms are method specifications
· Theorems are method implementations
· Other objects (definitions, etc) behave the same
· Inheritance is implicit
· Each class has a type
· Methods are projections
· IsA hierarchy is explicit, or maintained as theory dependencies
· Still support explicit methods
· Coercions can be provided (explicitely, or as a theory)
Points to consider
· Recursive classes
· True object-oriented operations?
Grand Unified Theory
· What are the components of formal methods?
· Term language (to specify syntax)
· Computation rules (like beta reduction)
· Inference rules (to define logics)
· Sequents
· Tactics
· Definitions
· Axioms
· Theorems
· Type theory
· Do we need them all?
What is a rule?
·
·
·
·
H:Sequent* × C:Sequent
If H are true, then C is true
H and C are types/propositions
In addition:
· H are assumed to be well-formed
· C is not only true, it is well-formed
· The sequent is [pointwise] functional
What is a theory?
· H:Type* × T:Type*
· H and T are well-formed
· If H are true, then T are true
Unify rules and theories by removing
well-formedness constraints
· Incorporate hierarchical nature
· Generalize sequents by making them recursive:
· H:(Sequent + Type) × C:(Sequent + Type)
· If H are true, well-formed, and functional, then C is true
· Main question: how do we talk about functionality of non-type
sequents?
· A traditional rule is an instance of a true sequent
· H:Sequent1* × C:Sequent1
· A theory is also a sequent
· A type theory is a sequent!
· One meta-rule: modus-ponens
The unification point:
· We can automatically convert between:
· Sequents
· Rules
· Theories
· Type theories
· Tactics
· Rest remain as-is:
· Computation rules
· Definitions (special case of computation)