the evolution of programming languages day 2 lecturer: xiao jia [email protected] the evolution of...
TRANSCRIPT
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