1 / 40

The Evolution of Programming Languages

The Evolution of Programming Languages. Day 2 Lecturer: Xiao Jia xjia@cs.sjtu.edu.cn. In last lecture …. Anomalies Theoretical Issues Type Theory REs and Control/Data Structures. The Procedural Paradigm. Early Days. ( address 104). Early Days. ( symbol a3). FORTRAN. 1957 IBM

dreama
Download Presentation

The Evolution of Programming Languages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Evolution of Programming Languages Day 2 Lecturer: Xiao Jia xjia@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 (address 104) The Evolution of PLs

  5. Early Days (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 S1D2 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) + 17 • Convert integer 8 to string ‘8’ • Concatenate strings ‘57’ and ‘8’  ‘578’ • Convert string ‘578’ to integer 578 • Add 17 to 578  595 • 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 The Evolution of PLs

More Related