the evolution of programming languages day 2 lecturer: xiao jia xjia@cs.sjtu.edu.cn the evolution of...

The Evolution of PLs 1

The Evolution of Programming Languages

Day 2Lecturer: Xiao Jiaxjia@cs.sjtu.edu.cn

The Evolution of PLs 2

In last lecture …

• Anomalies• Theoretical Issues

– Type Theory– REs and Control/Data Structures

The Evolution of PLs 3

The Procedural Paradigm

The Evolution of PLs 4

Early Days

Location Order100 A 104101 A 2102 T 104103 H 24104 C 50105 T 104

(address 104)

The Evolution of PLs 5

Early Days

A a3A 2T a3H 24

a3) C 50T a3

(symbol a3)

The Evolution of PLs 6

FORTRAN

• 1957• IBM• John Backus

The Evolution of PLs 7

• “The IBM Mathematical Formula Translation System or briefly, FORTRAN, will comprise a large set of programs to enable the IBM 704 to accept a concise formulation of a problem in terms of a mathematical notation and to produce automatically a high-speed 704 program for the solution of the problem.”

The Evolution of PLs 8

Major Achievements

• efficient compilation• separate compilation

(programs as separate subroutines, but the compiler doesn’t check for consistency between components)

• demonstration that high-level programming, with automatic translation to machine code, is feasible

The Evolution of PLs 9

Principal Limitations

• Flat, uniform structure– no concept of nesting

• Limited control structures– no compound statements

• Unsafe memory allocation– do NOT check consistent usage of memory

• No recursion– allocate data statically

The Evolution of PLs 10

Exercise

• The FORTRAN 1966 Standard stated that a FORTRAN implementation may allow recursion but is not required to do so.

• How would you interpret this statement if you were:

• (i) writing a FORTRAN program?• (ii) writing a FORTRAN compiler?

The Evolution of PLs 11

Algol 60

• Goal: universal PL• Algol was a failure

– few compilers, not widely used

• Algol was a success– standard language for describing algorithms

The Evolution of PLs 12

Major Innovations

• Block Structure– block: introduce nested scopes– runtime entity: activation record (AR) on stack

• Dynamic Arrays (discussed later)

– dope vector: a pointer and an integer (size)

• Call By Name (discussed later)

• Own Variables– keyword: own– analogy: static in C++ (within a function)

The Evolution of PLs 13

Exercise

• Own Variables:• local scope• global extent

• Discuss the initialization of own variables.

The Evolution of PLs 14

Dynamic Arrays

procedure average (n); integer n;

begin

real array a[1:n];

…

end;

The Evolution of PLs 15

Call By Name

procedure count (n); integer n;

begin

n := n + 1

end

count(widgets) begin widgets := widgets + 1 end

The Evolution of PLs 16

Call By Name

integer procedure sum (max, i, val);

integer max, i, val;

begin

integer s;

s := 0;

for i := 1 until n do

s := s + val;

sum := s

end

sum(3, i, a[i])computes

a[1]+a[2]+a[3]

The Evolution of PLs 17

Call By Name

try(x > 0, 1.0 / x)

The Evolution of PLs 18

Call By Name

try(x > 0, 1.0 / x)

real procedure try(b, x); boolean b; real x;

begin

try := if b then x else 0.0

end

The Evolution of PLs 19

Exercise

integer procedure sum (max, i, val);

integer max, i, val;

begin

integer s;

s := 0;

for i := 1 until n do

s := s + val;

sum := s

end

sum(3, i, a[i])computes

a[1]+a[2]+a[3]

Why does i appear in the parameter list of sum?

The Evolution of PLs 20

Missed Interesting Opportunities

• An Algol block without statements is, in effect, a record– Yet Algol 60 doesn’t provide records

The Evolution of PLs 21

Missed Interesting Opportunities

• An Algol block:– begin

• Declarations• Statements

– end

• A natural interpretation of concurrency:– begin D1 S1 D2 S2 end

The Evolution of PLs 22

Missed Interesting Opportunities

• Own variables: separation of scope and extent

• Ultimately lead to objects

The Evolution of PLs 23

Missed Interesting Opportunities

• Call By Name: first step towards the idea that functions can be treated as values

• Actual parameters are implemented as Algol calls of parameter-less procedures

• Apply the idea consistently throughout the language high order functions, and functional programming

The Evolution of PLs 24

• The Algol committee knew what they were doing

• “Missed opportunities” would have led to significant implementation problems

The Evolution of PLs 25

COBOL

• COmmon Business-Oriented Language

• structured data• implicit type conversionMOVE X to Y.

The Evolution of PLs 26

Example: Automatic conversion

SALARY PICTURE 99999, USAGE IS COMPUTATIONAL

SALREP PICTURE $$$,$$9.99

MOVE SALARY TO SALREP.

The Evolution of PLs 27

Exercise

• Despite significant advances in the design and implementation of PLs,it remains true that FORTRAN is widely used for “number crunching”, andCOBOL is widely used for data processing

• Explain why.

The Evolution of PLs 28

PL/I

• Design principles:• (i) contain features for all kinds of

programming• (ii) only have to learn a subset of the

language

The Evolution of PLs 29

PL/I is a failure

• A programmer who has learned a “subset” of PL/I is likely to make a mistake

The Evolution of PLs 30

Example: Automatic conversion

(‘57’ || 8) + 171. Convert integer 8 to string ‘8’

2. Concatenate strings ‘57’ and ‘8’ ‘578’

3. Convert string ‘578’ to integer 578

4. Add 17 to 578 595

5. Convert integer 595 to string ‘595’

The Evolution of PLs 31

Features

• Storage class: static, automatic, based, controlled

• Programmer-defined types (but could NOT be named)

• Exception handling

ON condition BEGIN; … END;

OVERFLOW

PRINTER OUT OF PAPER

The Evolution of PLs 32

Algol 68

• Design principle:

orthogonality

• The language is to be defined using a number of basic concepts that could be combined in arbitrary ways.

The Evolution of PLs 33

Features

• Described in formal notation (contribute to the slow acceptance of the language)

• Operator overloading (even priority can be altered)

• Very uniform notation for declarations and other entities: mode name = expression

• Reference• Large vocabulary of PL terms

The Evolution of PLs 34

Pascal

• Demonstrate that a PL could be simple yet powerful

• Data types form a recursive hierarchy (as blocks do in Algol 60)

• NO implicit type conversions• A kind of “fill in the blanks” language –

stepwise refinement– but prevents independent compilation

The Evolution of PLs 35

Modula-2

• inherits Pascal’s strengths• (to some extent) removes Pascal’s

weaknesses

• Important Features:• (i) Modules (interface, implementation)• (ii) Coroutines HOMEWORK

The Evolution of PLs 36

C

• Very pragmatic PL• Notable for its concise syntax

• Contribution: POPULARITY• the spread of UNIX inevitably led to the

spread of C

The Evolution of PLs 37

Ada

• represents the last major effort in procedural PL design

procedure procname ( parameters ) is body

type recordtype ( parameters ) is body

The Evolution of PLs 38

generic (parameters) package packagename is package description

task type templatename is task description

The Evolution of PLs 39

generic max: integer; type element is private; package Stack is …

package intStack is new Stack(20, integer)

The Evolution of PLs 40

Exercise

• Propose a uniform style for Ada declarations

HOMEWORK