Algol After FORTRAN Implementations Algol Report Algol's Objectives

Algol After FORTRAN Implementations Algol Report Algol's Objectives

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:

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    15 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us