Type Systems & Checking COMP 524: Programming Languages Based - - PowerPoint PPT Presentation

type systems checking
SMART_READER_LITE
LIVE PREVIEW

Type Systems & Checking COMP 524: Programming Languages Based - - PowerPoint PPT Presentation

Type Systems & Checking COMP 524: Programming Languages Based in part on slides and notes by J. Erickson, S. Krishnan, B. Brandenburg, S. Olivier, A. Block, and others Purposes - Implicit Context Compilers can infer information , so


slide-1
SLIDE 1

COMP 524: Programming Languages

Based in part on slides and notes by J. Erickson, S. Krishnan, B. Brandenburg, S. Olivier, A. Block, and others

Type Systems & Checking

slide-2
SLIDE 2
  • B. Ward — Spring 2014

Purposes - Implicit Context

➡Compilers can infer information, so

programmers write less code.

➡e.g., The expression a + b in Java may be adding

two integer, two floats or two strings depending

  • n context.

2

slide-3
SLIDE 3
  • B. Ward — Spring 2014

Purposes - Semantically Valid Information

➡Language system can detect semantic mistakes ➡e.g., Python’s list type supports append() and

pop(), but complex numbers do not

3

slide-4
SLIDE 4
  • B. Ward — Spring 2014

Type Systems

A type system consists of:

  • 1. A mechanism to define types and associate

them with language constructs.

  • 2. A set of rules for “type equivalence,” “type

compatibility,” and “type inference.”

4

slide-5
SLIDE 5
  • B. Ward — Spring 2014

Type Systems: Type Checking

Enforcement of type system rules.

➡Type Checking is the process of

ensuring that a program obeys the language’s type compatibility rules.

➡There are several ways to classify type

systems, discussed in the remainder of this section.

5

slide-6
SLIDE 6
  • B. Ward — Spring 2014

Strong vs. Weak Typing

6

Strongly typed languages always detect type errors:

➡All expressions and objects must have a type ➡All operations must be applied to operands of appropriate

types.

➡High assurance: any type error will be reported.


Weakly typed languages may “misinterpret” bits.

➡“anything can go” ➡Operations are carried out, possibly with unintended

consequences.

➡Example: adding two references might result in the sum of

the object’s addresses (which is nonsensical).

slide-7
SLIDE 7
  • B. Ward — Spring 2014

Strong vs. Weak Typing

Strongly typed languages always detect type errors:

➡All expressions and objects must have a type ➡All operations must be applied to operands of appropriate

types.

➡High assurance: any type error will be reported.


Weakly typed languages may “misinterpret” bits.

➡“anything can go” ➡Operations are carried out, possibly with unintended

consequences.

➡Example: adding two references might result in the sum of

the object’s addresses (which is nonsensical).

7

Strong typing is essential for secure execution of untrusted code!

  • Otherwise, system could be tricked

into accessing protected memory, etc.

slide-8
SLIDE 8
  • B. Ward — Spring 2014

Static vs. Dynamic Type Checking

8

Static Type Checking.

➡All checks performed at compile time. ➡Each variable/expression has a fixed type.


Dynamic Type Checking.

➡Only values have fixed type. ➡Expressions may yield values of different types. ➡All checks done necessarily at runtime.

slide-9
SLIDE 9
  • B. Ward — Spring 2014

Static Type Checking.

➡All checks performed at compile time. ➡Each variable/expression has a fixed type.


Dynamic Type Checking.

➡Only values have fixed type. ➡Expressions may yield values of different types. ➡All checks done necessarily at runtime.

Static vs. Dynamic Type Checking

9

This terminology is not absolute: most statically, strongly typed languages have a (small) dynamic component.

  • Example: disjoint union types in strongly

typed languages require tag checks at runtime.

slide-10
SLIDE 10
  • B. Ward — Spring 2014

Type Checking

Type Equivalence

➡When are the types of two values the same?

  • We’re primarily going to look at this one.


Type Compatibility:

➡Can a value of A be used when type B is expected?


Type Inference:

➡What is the type of expressions if no explicit type

information is provided?

➡If type information is provided by the programmer,

does it match the actual expression’s type?

10

slide-11
SLIDE 11
  • B. Ward — Spring 2014

Type Equivalence

When are two types semantically the same?

➡For example, when combining results from

separate compilation.

➡Two general ideas:

  • structural equivalence
  • name equivalence

➡In practice, many variants exist.

11

slide-12
SLIDE 12
  • B. Ward — Spring 2014

Structural Equivalence

Two types are structurally equivalent if they have equivalent components.

12

typedef struct{int a,b;} foo1; typedef struct { int a,b; } foo2;

Equivalent!

slide-13
SLIDE 13
  • B. Ward — Spring 2014

Structural Equivalence

Two types are structurally equivalent if they have equivalent components.

13

typedef struct{int a,b;} foo1; typedef struct{ int b; int a; } foo2;

Equivalent?

Yes, in most languages.

slide-14
SLIDE 14
  • B. Ward — Spring 2014

Structural Equivalence

Two types are structurally equivalent if they have equivalent components.

14

typedef struct{int a,b;} foo1; typedef struct{ int c; int d; } foo2;

Equivalent?

Yes, in most languages.

slide-15
SLIDE 15
  • B. Ward — Spring 2014

Structural Equivalence

15

typedef struct{ char *name; char *addre; int age; } student;

Equivalent...

typedef struct{ char *name; char *addre; int age; } school;

... but probably not intentional.

slide-16
SLIDE 16
  • B. Ward — Spring 2014

Name Equivalence

➡Name equivalence assumes that two

definitions with different names are not the same.

➡Programmer probably had a good reason to

pick different names…

➡Solves the “student-school” problem. ➡Standard in most modern languages.

16

slide-17
SLIDE 17
  • B. Ward — Spring 2014

Type Aliases / Type Synonyms

➡Under name equivalence, it may be

convenient to introduce alternative names.

➡E.g., for improved readability.

  • Can also make changing things easier.

➡Such a construction is called an alias.

17

typedef int customer_id;

slide-18
SLIDE 18
  • B. Ward — Spring 2014

Name Equivalence: Aliases

Two ways to interpret an alias:

➡Strict name equivalence

  • customer_id is different from int.
  • This is called a derived type.

➡ Loose name equivalence

  • customer_id is equivalent to int.
  • This is what C actually does.

18

typedef int customer_id;

slide-19
SLIDE 19
  • B. Ward — Spring 2014

Problem with Loose Equivalence

19

typedef double celsius_temp; typedef double fahren_temp; ... celsius_temp c; fahren_temp f; ... f = c; /* probably should be an error*/

slide-20
SLIDE 20
  • B. Ward — Spring 2014

Type Conversion - Type Mismatch

➡Intention: to use a value of one type in a context

where another type is expected.

  • E.g., add integer to floating point

➡Requires type conversion or type cast.

20

slide-21
SLIDE 21
  • B. Ward — Spring 2014

Type Conversion - Bit Representation

➡Different types may have different

representations.

➡Converting type cast: underlying bits are

changed

➡Non-converting type cast: bits remain

unchanged.

  • But are interpreted differently.
  • Useful for systems programming.

21

slide-22
SLIDE 22
  • B. Ward — Spring 2014

Type Coercion: Implicit Casts

When does casting occur?

➡Type coercion: compiler has rules to automatically

cast values in certain situations.

➡E.g., integer-to-float promotion. ➡Some languages allow coercion for user-defined

types (e.g., C++).


Two-edged feature.

➡Makes code performing arithmetic more natural. ➡Can hide type errors!

22

float x = 3;