Signature, Strong Typing

Signature I Specification of an operation, the number, order and types of the arguments in the domain of an operation + : integer x integer  integer = : integer x integer  Boolean SQRT : real  real op name : arg type x arg type x … arg type  result type Function prototype (C)

Signature II Situations that make difficult specifying an operation as a mathematical function Operations that are undefined for certain inputs Square-root, overflow나 underflow를 초래하는 연산 Implicit arguments Global variables, non-local identifier reference Side effect An operation may return an explicit result, but it also modify the values stored in other objects, both programmer- and system-defined … modification of input arguments Self-modification (history sensitivity) modify its own internal structure, either local data that are retained between executions or its code… random number generator .. Java, LISP …. Java에서 어떻게???? --- static type

Declarations float A, B; $abc = ‘a string’; $abc = 7; imax =7 DECLARE X FIXED DECIMAL (5,3)

Purposes for Declarations Choice of storage representation Storage management Lifetimes of data objects  memory class of C, C++ Polymorphic operations Resolving overload (generic) at compile time Type checking

Type checking Type error Runtime (dynamic type) checking  Compile time (static type) checking Dynamic type checking, typeless  flexibility in program design (polymorphism) Disadvantage Difficult to debug Type information must be kept during program execution Slowdown the execution speed

Information for Static type checking For each operation, the number, order, and data types of its arguments and results (i.e signature) The type of data object associated with a variable must be invariant … For each variable, the type of data object named The type of each constant data object

Static type checking …. In most languages, static type checking is not possible By dynamic type checking … high cost By leaving the operations unchecked …cause serious and subtle program errors

Strong Typing 컴파일 과정에서 모든 형 검증이 끝나는 (static type checking) 언어를strongly typed언어라고 한다. Algol 68은 strongly typed 언어이지만, PASCAL은 아니다.

Pascal ⒜ PASCAL에서 프로시듀어나 함수가 인자로 사용될 경우 번역 과정에서 형 검증을 할 수 없다. 경우 번역 과정에서 형 검증을 할 수 없다. precedure who_knows( i, j : integer; procedure f ); var k : boolean; begin k := j < i; if k then f(k) else f(i) end 위의 프로그램에서 컴파일러는 f(k)와 f(i)가 오류인지 아닌지 알 수 없다. 그 이유는 실질 인자(actual parameter)가 무엇인지에 따라 오류 여부가 결정되기 때문이다.

Algol Algol 68은 그와 같은 문제가 발생하지 않는다. proc who_knows = ( int i, int j, proc(bool) void f) void : begin bool k; k := j < i; if k then f(k) else f(j) error !!! fi end  C언어는?

다른 비교 Algol68에서는 위의 문제를 type이 맞지 않는 것으로 보지 않고, value가 맞지 않는 것으로 취급한다. (B) PASCAL에서 a, b, c가 1..10인 subrange 형일 경우에, "a := b + c"가 오류일지 아닐 지는 수행 시에만 알 수 있다 Algol68에서는 위의 문제를 type이 맞지 않는 것으로 보지 않고, value가 맞지 않는 것으로 취급한다.

다른 비교 ⒞ ⒟ PASCAL의 variant record는 번역시에 검증 못함 Algol 68의 union은 그렇지 않다. 수행 시 검증이 필요한 것은 프로그래머가 명시적으로 프로그램해야 한다. ⒟ PASCAL에서는 형 일치(type-compatibility)에 대한 규칙이 없지만, Algol 68은 명확히 정의되어 있다.

형 일치 이름 일치(Name equivalence) 구조적 일치(Structural equivalence) 두 변수의 형은 동일한 사용자 정의나 내장형 이름일 경우, 또는 같은 선언에 나타난 경우에만 일치한다. 따라서 d, e.b와 f.b는 같은 형이고, a와 b는 같은 형이며, e와 f 같은 형이다. 그러나 a와 c는 같은 형이 아니다. 구조적 일치(Structural equivalence) 두 변수는 같은 구조를 가지면 같은 형이다. 이 경우 a, b, c, d, e.b와 f.b는 같은 형이다.

실제 예 Algol 68은 구조적 일치 기법으로 형 일치를 검증하도록 정의되어 있다. PASCAL은 컴파일러 구현과정에서 정의되도록 되어있다. 따라서 같은 PASCAL 프로그램도 컴파일러에 따라 결과가 다를 수 있다. 대부분의 PASCAL 컴파일러는 구조적 일치를 사용하지만, 인자 교환(parameter passing)에서는 이름일치를 사용한다. 이름일치를 사용할 경우 정수 값을 정수의 subrange형인 변수에 형 변환(type conversion) 없이는 기억시킬(assign) 수 없다.

형 일치(Type compatibility) 프로그램의 예 type t = array[1..20] of integer; var a, b : array[1..20] of integer; c : array[1..20] of integer; d : t e, f : record a : integer; b : t end

숙제 pointer를 잘못 사용하면 생길 수 있는 오류와 이를 해결하는 각 프로그래밍 언어가 취하는 방법을 설명하라!!! PL 자습자료를 참고하면 됨 !!!!! C 언어에서 compile time에 type checking이 불가능한 예를 보여라.