Scribd
Upload
37 views22 pages

Types and Programming Languages: Simon Gay Department of Computing Science University of Glasgow

This document provides an introduction to types and programming languages. It discusses type definitions and declarations in languages like Java. It describes how compile-time type checking verifies that a program respects the programmer's declared types. While type checking is useful, it is an approximation as exact program analysis is impossible due to problems like the halting problem being undecidable. The document outlines principles of type system design and explains why studying types deepens understanding of programming languages and program semantics. It concludes with administrative details of the course.

Uploaded by

Zeph Dugang
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
37 views22 pages

Types and Programming Languages: Simon Gay Department of Computing Science University of Glasgow

This document provides an introduction to types and programming languages. It discusses type definitions and declarations in languages like Java. It describes how compile-time type checking verifies that a program respects the programmer's declared types. While type checking is useful, it is an approximation as exact program analysis is impossible due to problems like the halting problem being undecidable. The document outlines principles of type system design and explains why studying types deepens understanding of programming languages and program semantics. It concludes with administrative details of the course.

Uploaded by

Zeph Dugang
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 22

Types and Programming Languages

Lecture 1
Simon Gay
Department of Computing Science
University of Glasgow

2006/07

Introduction
Type definitions and declarations are essential aspects of
high-level programming languages.
Example (Java):
class Example {
int a;
void set(int x) {a=x;}
int get() {return a;}
}
Example e = new Example();

2006

Types and Programming Languages Lecture 1 -

Compile-time (static) typechecking is standard


From the Jikes Java compiler (applied to some other code):
7.

e.set(Hello);
^------------^
*** Semantic Error: No applicable overload for
the method named set was found in type
Example. Perhaps you wanted the overloaded
version void set(int x); instead?
8.

e.show();
^------^
*** Semantic Error: No method named show was
found in type Example.
2006

Types and Programming Languages Lecture 1 -

Compile-time (static) typechecking

9.

i = e + 1;
^
*** Semantic Error: The type of this
expression, Example, is not numeric.

2006

Types and Programming Languages Lecture 1 -

Type declarations
Organize data into high-level structures
essential for high-level programming
Document the program
basic information about the meaning of variables and
functions
Inform the compiler
example: how much storage each value needs
Specify simple aspects of the behaviour of functions
types as specifications is an important idea

2006

Types and Programming Languages Lecture 1 -

Typechecking
Static (compile-time) or dynamic (run-time)
static is better: finds errors sooner, doesnt degrade
performance
(we will concentrate on static typechecking)
Verifies that the programmers intentions (expressed by
declarations) are observed by the program
A program which typechecks is guaranteed to behave well
at run-time
at least: never apply an operation to the wrong type of value
more: eg. security properties
A program which typechecks respects the high-level
abstractions
eg: public/protected/private access in Java
2006

Types and Programming Languages Lecture 1 -

Why study types (and programming languages)?


The type system of a language has a strong effect on the feel
of programming.
Examples:
In original Pascal, the result type of a function cannot be an
array type. In Java, an array is just an object and arrays can
be used anywhere.
In Haskell, programming with lists is very easy; in Java it is
much less natural.
To understand a language fully, we need to understand its type
system. We will see underlying typing concepts appearing in
different languages in different ways, helping us to compare
and understand language features.
2006

Types and Programming Languages Lecture 1 -

Why study types (and programming languages)?


How does a language designer (or a programmer) know that
correctly-typed programs really have the desired run-time
properties?
To answer this question we need to see how to specify type
systems, and how to prove that a type system is sound.
To prove soundness we also need to specify the semantics
(meaning) of programs - what happens when they are run.
So studying types will lead us to a deeper understanding of
the meaning of programs.
Example of the issue of soundness: variant records in Pascal

2006

Types and Programming Languages Lecture 1 -

Variant records in Pascal


type kind = (staff,student);
type person =
record
name : string;
case k : kind of
staff : (office : string)
student : (year : integer)
end;
The following error cannot be detected by static typechecking:
var simon : person;
begin simon.name := Simon; simon.k := staff;
simon.office := G093; write(simon.year + 5);
end
2006

Types and Programming Languages Lecture 1 -

Variant records in Ada


type kind = (staff,student);
type person(k : kind) is
record
name : String;
case k is
when staff => (office : String)
when student => (year : Integer)
end case;
end record;
Now we must declare simon : person(staff) and then
simon.year is never allowed.

2006

Types and Programming Languages Lecture 1 -

10

Possibilities and limitations of typechecking


If types are specifications, can typechecking be used to verify
program properties beyond correct use of data and functions?
Yes, for example:
secrecy and authenticity properties of security protocols
behavioural properties (eg. deadlock-freedom) in
concurrent systems
But there are limits: most interesting properties cannot be
automatically verified, even in principle, so types can only ever
give a safe approximation to correctness.
Also, in practice we want typechecking to be efficient.

2006

Types and Programming Languages Lecture 1 -

11

Typechecking as a safe approximation


For any static type system, and the notion of correctness which
it aims to guarantee:
It is essential that every typable program is correct.
It is usually impossible to ensure that every correct program is
typable.
Typechecking must not accept any incorrect programs but
always rejects some correct programs.
Exercise: write down a fragment of Java code which will not
typecheck but which, if executed, would not misuse any data.
2006

Types and Programming Languages Lecture 1 -

12

Answer to exercise
if (1 == 2) {
int x = Hello * 5;
}
The Java typechecker assumes that every branch of a
conditional statement may be executed (even if the condition is
a compile-time constant or even a boolean literal).
In general it is impossible to predict the value of an arbitrary
expression at compile-time.

2006

Types and Programming Languages Lecture 1 -

13

Principles
Programming is difficult and we need all the automated help we
can get!
Static typechecking is one approach to program analysis.
It has been enormously beneficial.
Exact program analysis is impossible in general. Typechecking
aims for limited guarantees of correctness, and inevitably
rejects some correct programs.
A type system restricts programming style, sometimes to an
undesirable extent.
The challenge in type system design: allow flexibility in
programming, but not so much flexibility that incorrect programs
can be expressed.
2006

Types and Programming Languages Lecture 1 -

14

Why exact program analysis is impossible


This is probably familiar from any course on computability
Some problems are undecidable - it is impossible to construct
an algorithm which will solve arbitrary instances.
The basic example is the Halting Problem: does a given program
halt (terminate) when presented with a certain input?
Problems involving exact prediction of program behaviour are
generally undecidable, for example:
does a program generate a run-time type error?
does a program output the string Hello?
We cant just run the program and see what happens, because
there is no upper limit on the execution time of programs.
2006

Types and Programming Languages Lecture 1 -

15

Undecidability of the Halting Problem (HP)


Instance of HP: a legal program P and an input string S for P.
Question: does P halt when run on S?
Theorem: HP is undecidable
Proof: by contradiction - we assume that we have an algorithm
A that solves HP, and discover that the consequence of this
assumption is a logical impossibility. Therefore the assumption
must be false.
Concretely, say P is a Java function:
void P(String S);
Let H be an implementation of algorithm A as a Java function:
boolean H(String X, String S);
Any language can be substituted for Java.
2006

Types and Programming Languages Lecture 1 -

16

Undecidability of the Halting Problem (HP)


Using H we can define a Java function Q:
Q is given a legal Java function W
Q uses H to determine whether or not W halts when given its
own text as input
if W halts then Q enters an infinite loop, otherwise Q halts
void Q(String W) {
if (H(W,W)) {
while (true) {}
}
}

2006

Types and Programming Languages Lecture 1 -

17

Undecidability of the Halting Problem (HP)


Now we run Q with its own text as input. What happens?
Q(void Q(String W) {})
Q calls H(Q,Q) which returns either true or false.
If H returns true then:
from the definition of H, Q halts on input Q.
from the definition of Q, Q loops on input Q.
CONTRADICTION!
If H returns false then:
from the definition of H, Q loops on input Q.
from the definition of Q, Q halts on input Q.
CONTRADICTION!
Therefore Q cannot exist.
2006

Types and Programming Languages Lecture 1 -

18

Consequences for program analysis


The question Does program P generate a run-time type error
with input S? is undecidable. If R were a decision procedure
for this question then we could solve HP for program P
by using R to analyse
void NewP(String S) {
P(S);
int x = 1 + Hello;
}
because NewP generates a type error if and only if P halts.
Similarly for any other behavioural property of programs.
2006

Types and Programming Languages Lecture 1 -

19

All is not lost


This sounds rather bleak, but:
static analysis (including type systems) is a huge and
successful area
incomplete analysis (remember: safe approximation) is better
than no analysis, as long as not too many correct programs
are ruled out
A major trend in programming language development has been
the inclusion of more sophisticated type systems in mainstream
languages.
By studying more powerful type systems, we can get a glimpse
of what the next generation of languages might look like.
2006

Types and Programming Languages Lecture 1 -

20

Administrative details
Two lectures + one tutorial per week (Mon 11, Wed 9, Fri 10).
Copies of presentations will be handed out.
Some additional notes will be produced.
There will be an assessed exercise (worth 20%) and an exam.
A sample exam paper will be produced.
I can be contacted by email ([email protected]), or in my
office (G093) within reason.
Books: Types and Programming Languages, B. C. Pierce
compiler books
Type Systems, L. Cardelli (material for reading course)
Course web page:
2006

www.dcs.gla.ac.uk/~simon/teaching/tpl

Types and Programming Languages Lecture 1 -

21

Reading and Exercises


For each hour of timetabled teaching you should expect to
spend at least another hour on private study. After each lecture
I will recommend reading from Pierces book; often I will also
assign exercises from the book or from additional worksheets.
During the tutorial sessions we can discuss any problems
which arise from the reading or the exercises.
For now:
Read Chapter 1 of Pierce.
Refer to Chapter 2 of Pierce as necessary, during the rest of
the course.
Read Sections 1 and 2 of Linear Types for Packet Processing.
2006

Types and Programming Languages Lecture 1 -

22

You might also like