CS 342 Lecture -*- Outline -*-

* Type checking

** strong vs. weak type checking
**	strongly typed languages have representation independence
		programs cannot observe, access, or modify variables
		 in ways that are inconsistent with their types.
		=> representation independence
	-no way to treat boolean as an integer (in Algol 60)
	-leads to portable code
		-in FORTRAN, equivalence, common can be used to violate
			strong typing
***	untyped language: programs have access to representation (bits)
		-in BCPL
		-same as having a single type (or type depends only on size)
		-arguing that untyped language leads to nonportable code
			is fallacious (Flon's axiom)
		-harder to point out conceptually distinct data abstractions
		-less security (since less redundant information)

** static vs. dynamic type checking
***	static type checking: type errors caught before run-time (statically)
		-as in Algol 60, Pascal, etc.
		-in language with separate compilation, may have to catch
			type errors at link-time
		-in FORTRAN some type errors are not caught
			(between procedures)
***	dynamic type checking: type errors caught at run-time
		(trying to apply operation to data having wrong format)
		-how? requires tag bits on data to tell type
		-as in LISP, SNOBOL 4, Smalltalk