Signature, Strong Typing

1. Signature, Strong Typing

2. 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)

3. 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

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

5. 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

6. 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

7. 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

8. 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

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

10. 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)가 무엇인지에 따라 오류 여부가 결정되기 때문이다.

11. 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언어는?

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

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

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

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

16. 형 일치(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

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