Algol After FORTRAN Implementations Algol Report Algol's Objectives
Total Page：16
File Type：pdf, Size：1020Kb
9/19/13 After FORTRAN • International language is needed – 1964: New language is proposed to break Algol away from platform dependence – Preliminary spec: NPL (new programming language), then PL/I (programming CS4100 language 1) From Principles of Programming Languages: Design, Evaluation, and Implementation (Third Edition), by – PL/I is too big Bruce J. MacLennan, Chapters 3and 4, and based on • Dijkstra: If Fortran is an infantile disorder, then slides by Istvan Jonyer. PL/I is a fatal disease • Trying to be everything to everyone backfires 1 2 Chapter 3: Generality and Implementations Hierarchy: ALGOL-60 • Because of the hype, many started • An international language is needed implementation quickly – This resulted in many dialects – A single, universal language would be – JOVIAL (Jules’ Own Version of the International valuable Algebraic Language) – International (American and European) • Committee meets again in 1960 to committee is set up to make incorporate suggestions recommendations – Algol-60 is born and is very different from the ’58 report. – Algol-58 is created in 8 days in Zurich, as a – Report is 17 pages long: remarkable achievement, preliminary report mainly due to BNF notation (reports used to – Algol: Algorithmic Language stretch to hundreds or thousands of pages) 3 4 Algol Report Algol’s Objectives • 1959 UNESCO Conference on Information Processing • The language should be very close to – Backus presents a description of Algol ‘58 • Uses formal syntax he developed mathematical notation – Naur is editor of Algol Bulletin • Should be useful in publications to • Disagrees with some of Backus’ interpretation • Need for more precise description describe algorithms • Develops a variant of Backus’ formal syntax • Mechanically translatable to machine Backus-Naur Form, aka BNF used for 1960 Algol code Report 5 6 1 9/19/13 Structural Organization Constructs • Declarative or Imperative • Hierarchically structured language – (like in FORTRAN) – Nesting is introduced (Fortran did not use nesting) • Variable declarations – Control structures can also be nested – Types: integer, real, Boolean integer i, j, k • One can be made the body of the other – Lower bounds of arrays need not be 1 if N > 0 then real array Data[-50:50] for i := 1 step 1 until N do – Switch, like FORTRAN’s computed GOTO sum := sum + Data[i] • Subprogram declarations • Advantage: decreases the number of GOTOs required – Keyword: procedure and – Procedures can be typed (functions) and untyped • Reserved words real procedure dist(x1, y1, x2, y2); real x1, y1, x2, y2; dist = sqrt((x1 – x2)^2 + (y1 – y2)^2) 7 8 Imperative Constructs Imperative Constructs • Computational • Control-flow – Assignment: “variable := expression” – All imperative constructs alter flow of – Operators: control (except assignment) • Arithmetic: +, -, *, etc. – Has if-then-else • Relational: =, <, >, ≥, etc. – for-loop replaces do-loop • Logic: ∧, ∨, ¬, etc. – Why is assignment ‘:=’ and not ‘=’? • No input/output constructs • Assignment is different from definition and – I/O was left to be handled by platform- comparison dependent library calls • I = I + 1 ; I := I + 1 9 10 Name Structures Syntax - Program • Algol-60 introduces the compound statement • <program> ::= <block> | <compound statement> – Where 1 statement is allowed, more can be used, using begin-end • <block> ::= <unlabelled block> | <label>: <block> for i := 1 step 1 until N do • <compound statement> ::= <unlabelled compound> | <label>: sum := sum + Data[i] <compound statement> for i := 1 step 1 until N do • <unlabelled compound> ::= begin begin <compound tail> sum := sum + Data[i]; • <unlabelled block> ::= Print Real (sum) <block head> ; <compound tail> end – Also, the body of a procedure is a single statement 11 12 2 9/19/13 Syntax - Statement Syntax - Block • <compound statement> ::= <unlabelled compound> | <label>: <compound statement> • <block> ::= <unlabelled block> | • <unlabelled compound> ::= begin <compound tail> <label>: <block> • <compound tail> ::= <statement> end | <statement> ; <compound tail> • <unlabelled block> ::= • <statement> ::= <unconditional statement> | <conditional statement> | <block head> ; <compound tail> <for statement> • <block head> ::= begin <declaration> | • <unconditional statement> ::= <basic statement> | <compound statement> | <block> <block head> ; <declaration> • <basic statement> ::= <unlabelled basic statement> | • <compound tail> ::= <statement> end | <label>: <basic statement> <statement> ; <compound tail> • <unlabelled basic statement> ::= <assignment statement> | <go to statement> | <dummy statement> | <procedure statement> 13 14 Blocks Define Nested Scopes Name Binding • Fortran • Fortran binds a variable to a single memory – Had local and global declarations only location statically – Had to redeclare using COMMON to share • Algol-60 included the results of research done • Algol-60 on name structures, which were problematic – Introduces blocks in Fortran begin – Sharing of data between subprograms declarations; – Parameter passing modes statements end – Return values – Compound statements do not have ‘declarations’. – Dynamic arrays – All declarations are visible to all statements in the block • Result of research: block structure – Since statements can be blocks, scopes can be nested 15 16 Why do we need scopes? “COMMON” with Blocks • Reduce the context programmers have to keep in • The error-prone COMMON in Fortran can be mind implemented in a much better way using • Make understanding and maintenance of program blocks easier begin • Scopes reduce visibility of names integer array Name, Loc, Type[1:100]; procedure Lookup (n); – Declare variable only where needed and used . Lookup procedure . • Nested blocks inherit names from outside procedure Var (n, l, t); – It would be very inconvenient if they did not . Var procedure . procedure Array1 (n, l, t, dim1); . Array1 procedure . end 17 18 3 9/19/13 Too Much Access Contour Diagrams • Blocks provide “indiscriminate access” • Inner blocks implicitly inherit access to all variable in immediately surrounding block – Since functions must be accessible to • Names declared in a block are local to the block users, • Names declared in surrounding blocks are nonlocal – and data structures must be accessible to • Names declared in outermost block are global functions – à Data is also accessible to users • Violates information hiding principle 19 20 Contour Diagrams Dynamic vs Static Scoping • See Figure 3.3, page 102 • Static scoping – Procedure is called in the context of its declaration • Do Exercise 3-1, page 104 • Environment of Definition – Scope structure is determined at compile-time – Algol • Dynamic scoping – Procedure is called in the context of its caller • Environment of Caller – Scope structure is determined at run-time – LISP 21 22 Example Dynamic Scopes and Functions • Draw static contour diagram • Draw dynamic contour diagram for both calls to P • Dynamic scoping applies to all names (not just a:begin variables) integer m outer m procedure P • Advantage: m := 1; – We can write a general procedure that makes use of b:begin procedures in the caller’s environment integer m; inner m • No need to have all names defined in static context P inner call • Disadvantage: end – If caller’s environment provides a different function than P outer call what is intended to be used (see example page 109) end • Programmer has to think about envt when writing calls 23 24 4 9/19/13 Blocks Permit Which one is better? Efficient Storage Management • General rule: • Fortran used EQUIVALENCE – What is natural to humans will cause less problems in the – Not safe, since there is no guarantee of exclusive use of long run memory – If humans can understand static scoping better, than it will • Blocks permit reuse of memory result in higher quality programs in the long run a:begin integer m, n; • Dynamic scoping is confusing b:begin real array X[1:100], real y; – Generally rejected (not used in new languages) ... – Static scoping agrees more with the program’s dynamic end behavior ... c:begin integer k; real array M[0:50]; ... end 25 end 26 Run-Time Stacks Example • Variables in blocks b and c are never used at the same time • From previous program • When exiting b, its variables may be discarded y • Notice: Block entered last will be exited first M – LIFO (last-in first-out) order X – Can use a stack to organize activation records k – When block is entered, its AR is pushed onto stack n n n – When block is exited, its AR is popped off stack n n enter (a) enter (b) m exit (b) enter (c) m exit (c) m exit (a) – Assumption: No local variables are initialized m m … … … … … 27 28 Responsible Design Principles of Programming • Algol designers did not include • The Responsible Design Principle EQUIVALENCE – Do not ask programmers what they want, – Programmers might have asked for it… find out what they need. – Instead, they looked at the root of the problem – “Don’t ask what they want, ask how the problem arises” – Language designers are responsible for the features in the language, not programmers 29 30 5 9/19/13 Data Structures Why no complex? • Primitives • Not primitive – Mathematical scalars, like in Fortran – Can be constructed using other types easily (2 reals) – integer, real, Boolean • Is it easy to use reals for complex? – complex and double not included – Yes, but inconvenient • Double: platform dependent – Need supporting operations – Not portable • ComplexAdd(x, y, z), etc. – Why? Because we need to know the size of a • Designers’ choice: