Programming Languages: Design, Specification, and Implementation

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

2. Outline • Conceptual Background • Requirements of Programming Languages • Specification vs. Implementation • Syntax, Semantics, Types, Static Analysis • Language Paradigms • Imperative: FORTRAN, Cobol, Algol, Pascal, PL/I, C • Applicative: LISP, Scheme, ML • Object-oriented: Smalltalk, Java • “Fourth-generation”: SETL, SQL • Logic Programming: Prolog • Concurrent-Distributed: Concurrent Pascal, Hermes • Languages vs. “Tools”/Patterns • Implementation Issues • Compile time: parsing, type analysis, static checking • 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 • 4th generation languages • Concurrency and Distribution: memory models, • Implementation issues

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

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) • Optional exercises 3.5.16, 8.3.8 • Scott, chapter 2, section 1 • How do we define tokens and syntax • Gelernter chapter 3, sections 1-2 • Introduction to FORTRAN and Algol 60

7. Issues in Language Design • Dijkstra, “Goto Statement Considered Harmful”, • 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 • Hoare, “An Axiomatic Basis For Computer Programming”, • 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 • Parnas, “On the Criteria to be Used in Decomposing Systems into Modules”, • http://www.acm.org/classics/may96/

8. Scope • General purpose high-level programming languages • Excludes: • Machine languages • Assembly languages • “Scripting” languages • Markup languages • Special purpose languages (e.g. report writing) • 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 <k, v>, where k is an integer and v is any string • Deliver a list of output tuples such that • If tuple <k, v> appears n times in input, it appears n times in output • If tuple <k, v> appears n times in output, it appears n times in input • For any two successive tuples <k1, v1> and <k2,v2> in output, k1 <= k2 • 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 • 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 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

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

13. $18.5 Million Bug (?) IF (TVAL .LT. 0.2E-2) GOTO 40 DO 40 M = 1, 3 W0 = (M-1)*0.5 X = H*1.74533E-2*W0 DO 20 N0 = 1, 8 EPS = 5.0*10.0**(N0-7) CALL BESJ(X, 0, B0, EPS, IER) IF (IER .EQ. 0) GOTO 10 20 CONTINUE DO 5 K = 1. 3 T(K) = W0 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 E(K) = H**2*93.2943*W0/SIN(W0)*Z H = D(K)-E(K) 5 CONTINUE 10 CONTINUE 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. • 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 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 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 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 software set a flag variable by incrementing it. Occasionally an arithmetic overflow occurred, causing the software to bypass safety checks. • 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.

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