CS 641 Lecture -*- Outline -*-

* Review of types and type checking

	idea: (static) analysis to verify certain program properties
		ostensibly to prevent type errors

** What is a "type"?

***	Specifications: abstract data type
		behavior included

***	Models (of specifications)
	Donahue: all objects are bit strings,
		want to make sure don't misinterpret them
	PER Model: type is a partial equivalence relation (over Nat)
		e.g., Bool = {<x,y>| x, y < 128 and x = y mod 2}

***	type checking: name (or expression)
		no notion of behavior directly

***	link between these views is focus of our study
		e.g., comparing types by nanme ensures that
		types of user-defined data distinct unless from
			same declaration (i.e., same module, implementation)

** What is a type error?
	assignment of variable of type S a value of type T?
		so what?
	treating a S as a T? (why do we care?)
		what is meant by "treating"

***	Seals (Morris, 1973)
		attempted violation of "seal" around object
		want to preserve invariants,
			so have inductive proof of safety properties
				(e.g., no duplicates in a list)
			induction needs to examine all places data is
				created or mutated
		prevent alteration, discovery, impersonation
			alteration: change of state without use of operations
			discovery: access to components without use of ops
			impersonation: some object not created by ops acts
				as if it was.

****		seal mechanism
			createseal -> (seal_t, unseal_t)
				gives unique seal function and matching key
				e.g., cryptosystem
			unseal_t(seal_t(x)) = x
			unseal_t(anything else) is an error

****		invariant preservation
			want to prove for all x: P(unseal_t(x))
			must show that for all y:
				if seal_t is applied to y,
				then P(y) holds.

			idea: limit use of seal_t to a small area of code

** Representation independence
	want to be able to change representation of types
		(built in and user-defined)
	can be ensured by proper notion of type error
		either checked statically or dynamically