1. Programming Languages: Design, Specification, and Implementation G22.2210-001 Rob Strom September 7, 2006

2. Outline  Conceptual Background Requirements of Programming Languages Requirements of Programming Languages Specification vs. Implementation Specification vs. Implementation Syntax, Semantics, Types, Static Analysis Syntax, Semantics, Types, Static Analysis  Language Paradigms Imperative: FORTRAN, Cobol, Algol, Pascal, PL/I, C Imperative: FORTRAN, Cobol, Algol, Pascal, PL/I, C Applicative: LISP, Scheme, ML Applicative: LISP, Scheme, ML Object-oriented: Smalltalk, Java Object-oriented: Smalltalk, Java “Fourth-generation”: SETL, SQL “Fourth-generation”: SETL, SQL Logic Programming: Prolog Logic Programming: Prolog Concurrent-Distributed: Concurrent Pascal, Hermes Concurrent-Distributed: Concurrent Pascal, Hermes Languages vs. “Tools”/Patterns Languages vs. “Tools”/Patterns  Implementation Issues Compile time: parsing, type analysis, static checking Compile time: parsing, type analysis, static checking Run time: parameter passing, garbage collection, method dispatching, remote invocation, just-in-time compiling, parallelization Run time: parameter passing, garbage collection, method dispatching, remote invocation, just-in-time compiling, parallelization

3. Tentative Outline  Motivations, Universals  Fortran and Algol 60 models: recursion and the stack  Algol 68, parameter passing, PL/I, C, heap  Functional programming: Scheme  Formal type systems: ML  Object-oriented languages: objects, inheritance, C++  Ada: packages, generics  Patterns and Pitfalls in Imperative Languages  Logic Programming  4 th generation languages  Concurrency and Distribution: memory models,  Implementation issues

4. Readings  Main Text: David Gelernter and Suresh Jagannathan: “Programming Linguistics”, MIT Press, 1990. David Gelernter and Suresh Jagannathan: “Programming Linguistics”, MIT Press, 1990.  Secondary Texts Michael L. Scott: “Programming Language Pragmatics”, Academic Press, 2000. Michael L. Scott: “Programming Language Pragmatics”, Academic Press, 2000. Benjamin C. Pierce: “Types and Programming Languages”, MIT Press, 2002 Benjamin C. Pierce: “Types and Programming Languages”, MIT Press, 2002  Language References: Giannesini et al: “Prolog”, Addison-Wesley 1986. Giannesini et al: “Prolog”, Addison-Wesley 1986. Gosling et al: “The Java Language Specification”, http://java.sun.com/docs/books/jls/ Gosling et al: “The Java Language Specification”, http://java.sun.com/docs/books/jls/http://java.sun.com/docs/books/jls/ Dewhurst & Stark, “Programming in C++”, Prentice Hall, 1989. Dewhurst & Stark, “Programming in C++”, Prentice Hall, 1989. Ada 95 Reference Manual, http://www.adahome.com/rm95/ Ada 95 Reference Manual, http://www.adahome.com/rm95/http://www.adahome.com/rm95/ MIT Scheme Reference MIT Scheme Reference http://www-swiss.ai.mit.edu/projects/scheme/documentation/scheme.htmlhttp://www-swiss.ai.mit.edu/projects/scheme/documentation/scheme.html Strom et al: “Hermes: A Language for Distributed Computing”, Prentice-Hall, 1991. Strom et al: “Hermes: A Language for Distributed Computing”, Prentice-Hall, 1991. Other sources: Other sources: R. Kent Dybvig, “The SCHEME Programming Language”, Prentice Hall, 1987.R. Kent Dybvig, “The SCHEME Programming Language”, Prentice Hall, 1987. Jan Skansholm, “ADA 95 From the Beginning”, Addison Wesley, 1997.Jan Skansholm, “ADA 95 From the Beginning”, Addison Wesley, 1997.

5. Grading  Programming Projects – 60%  Other required homework – 10%  Final examination – 30%

6. First 2 Lectures: Readings  Pierce, chapters 2, 3, 8 (formal operational semantics) (formal operational semantics) Optional exercises 3.5.16, 8.3.8 Optional exercises 3.5.16, 8.3.8  Scott, chapter 2, section 1 How do we define tokens and syntax How do we define tokens and syntax  Gelernter chapter 3, sections 1-2 Introduction to FORTRAN and Algol 60 Introduction to FORTRAN and Algol 60

7. Issues in Language Design  Dijkstra, “Goto Statement Considered Harmful”, http://www.acm.org/classics/oct95/#WIRTH66 http://www.acm.org/classics/oct95/#WIRTH66 http://www.acm.org/classics/oct95/#WIRTH66  Backus, “Can Programming Be Liberated from the von Neumann Style?” http://www.stanford.edu/class/cs242/readings/backus.pdf http://www.stanford.edu/class/cs242/readings/backus.pdf  Hoare, “An Axiomatic Basis For Computer Programming”, http://www.spatial.maine.edu/~worboys/processes/hoare%20axiomatic.pdf http://www.spatial.maine.edu/~worboys/processes/hoare%20axiomatic.pdf http://www.spatial.maine.edu/~worboys/processes/hoare%20axiomatic.pdf  Hoare, “The Emperor’s Old Clothes”, http://www.braithwaite-lee.com/opinions/p75-hoare.pdf http://www.braithwaite-lee.com/opinions/p75-hoare.pdf http://www.braithwaite-lee.com/opinions/p75-hoare.pdf  Parnas, “On the Criteria to be Used in Decomposing Systems into Modules”, http://www.acm.org/classics/may96/ http://www.acm.org/classics/may96/ http://www.acm.org/classics/may96/

8. Scope  General purpose high-level programming languages  Excludes: Machine languages Machine languages Assembly languages Assembly languages “Scripting” languages “Scripting” languages Markup languages Markup languages Special purpose languages (e.g. report writing) Special purpose languages (e.g. report writing) Graphical languages Graphical languages

9. How do we judge languages?  Compactness – writability/expressibility  Readability – ease of validation  Familiarity of Model  Less Error-Prone  Portability  Hides Details – simpler model  Early detection of errors  Modularity – Reuse  Modularity – Composability  Modularity – Isolation  Performance Transparency  Optimizability

10. Program Specifications  What properties a solution will meet  E.g: Accept a list of input tuples looking like, where k is an integer and v is any string Accept a list of input tuples looking like, where k is an integer and v is any string Deliver a list of output tuples such that Deliver a list of output tuples such that If tuple appears n times in input, it appears n times in outputIf tuple appears n times in input, it appears n times in output If tuple appears n times in output, it appears n times in inputIf tuple appears n times in output, it appears n times in input For any two successive tuples and in output, k1 and in output, k1 <= k2 Provided (some restriction, e.g. max number/range of tuples) Provided (some restriction, e.g. max number/range of tuples)  Doesn’t necessarily say how to compute a solution, and preferably allows for many possible solutions  Usually more compact than an implementation

11. Language Specifications  Given a “program text” How to tell whether it is a valid expression in the language How to tell whether it is a valid expression in the language What it “means” as a specification or an implementation of a program What it “means” as a specification or an implementation of a program  Usually, also: How to take a “chunk” of a “program text” How to take a “chunk” of a “program text” How to determine what it means as a specification of a component How to determine what it means as a specification of a component How to put together the specifications of components to define the specification of the program How to put together the specifications of components to define the specification of the program

12. Universals  Syntax: lexical and syntactic levels  Naming: Defining and applied occurrences Defining and applied occurrences Scope Scope  Types  Semantics Operational Operational Denotational Denotational Algebraic Algebraic

13. $18.5 Million Bug (?) IF (TVAL.LT. 0.2E-2) GOTO 40 IF (TVAL.LT. 0.2E-2) GOTO 40 DO 40 M = 1, 3 DO 40 M = 1, 3 W0 = (M-1)*0.5 W0 = (M-1)*0.5 X = H*1.74533E-2*W0 X = H*1.74533E-2*W0 DO 20 N0 = 1, 8 DO 20 N0 = 1, 8 EPS = 5.0*10.0**(N0-7) EPS = 5.0*10.0**(N0-7) CALL BESJ(X, 0, B0, EPS, IER) CALL BESJ(X, 0, B0, EPS, IER) IF (IER.EQ. 0) GOTO 10 IF (IER.EQ. 0) GOTO 10 20 CONTINUE DO 5 K = 1. 3 DO 5 K = 1. 3 T(K) = W0 T(K) = W0 Z = 1.0/(X**2)*B1**2+3.0977E-4*B0**2 Z = 1.0/(X**2)*B1**2+3.0977E-4*B0**2 D(K) = 3.076E-2*2.0*(1.0/X*B0*B1+3.0977E-4*(B0**2-X*B0*B1))/Z D(K) = 3.076E-2*2.0*(1.0/X*B0*B1+3.0977E-4*(B0**2-X*B0*B1))/Z E(K) = H**2*93.2943*W0/SIN(W0)*Z E(K) = H**2*93.2943*W0/SIN(W0)*Z H = D(K)-E(K) H = D(K)-E(K) 5 CONTINUE 10CONTINUE Y = H/W0-1 Y = H/W0-1 40 CONTINUE http://www-aix.gsi.de/~giese/swr/mariner1.html

14. 2003 North American blackout  The XA/21 monitoring software runs on Unix and is made of of several subsysystems. According to hacker journalist Kevin Poulsen, the bug was a race condition in the one-million lines of C++ code that made up the event processing subsystem. Kevin PoulsenKevin Poulsen  According to Mike Unum, manager at GE Energy in Melbourne, Florida: “There was a couple of processes that were in contention for a common data structure, and through a software coding error in one of the application processes, they were both able to get write access to a data structure at the same time. And that corruption led to the alarm event application getting into an infinite loop and spinning.”

15. Therac-25 Radiation Therapy  Software bugs caused overdoses; 5 died The design did not have any hardware interlocks to prevent the electron-beam from operating in its high-energy mode without the target in place. The design did not have any hardware interlocks to prevent the electron-beam from operating in its high-energy mode without the target in place.interlocks The engineer had reused software from older models. These models had hardware interlocks that masked their software defects. Those hardware safeties had no way of reporting that they had been triggered, to at least indicate the existence of faulty software commands. The engineer had reused software from older models. These models had hardware interlocks that masked their software defects. Those hardware safeties had no way of reporting that they had been triggered, to at least indicate the existence of faulty software commands.reused The hardware provided no way for the software to verify that sensors were working correctly (see open-loop controller). The table-position system was the first implicated in Therac-25's failures; the manufacturer gave it redundant switches to cross-check their operation. The hardware provided no way for the software to verify that sensors were working correctly (see open-loop controller). The table-position system was the first implicated in Therac-25's failures; the manufacturer gave it redundant switches to cross-check their operation.open-loop controlleropen-loop controller The equipment control task did not properly synchronize with the operator interface task, so that race conditions occurred if the operator changed the setup too quickly. This was evidently missed during testing, since it took some practice before operators were able to work quickly enough for the problem to occur. The equipment control task did not properly synchronize with the operator interface task, so that race conditions occurred if the operator changed the setup too quickly. This was evidently missed during testing, since it took some practice before operators were able to work quickly enough for the problem to occur.tasksynchronizerace conditionstasksynchronizerace conditions The software set a flag variable by incrementing it. Occasionally an arithmetic overflow occurred, causing the software to bypass safety checks. The software set a flag variable by incrementing it. Occasionally an arithmetic overflow occurred, causing the software to bypass safety checks.flag variablearithmetic overflowflag variablearithmetic overflow The software was written in assembly language. While this was more common at the time than it is today, assembly language is harder to debug than most high- level languages. The software was written in assembly language. While this was more common at the time than it is today, assembly language is harder to debug than most high- level languages.assembly languageassembly language

16. BNF expr ::= expr “+” term | expr “–” term | term term ::= term “*” factor | term “/” factor | factor factor ::= number | identifier | “(“ expr “)”