Lecture 11: Fixing Fixed Points On to Language Design

1. Lecture 11: Fixing Fixed Points On to Language Design “The Algol60 report was a fitting display for the language. Nicely organized, tantalizingly incomplete, slightly ambiguous, difficult to read, consistent in format, and brief, it was a perfect canvas for a language that possessed those same properties. Like the Bible it was meant, not merely to be read, but to be interpreted.” Alan Perlis, The American Side of the Development of Algol, ACM SIGPLAN Noticies, August 1978. David Evans http://www.cs.virginia.edu/~evans CS655: Programming Languages University of Virginia Computer Science

2. Menu • Quick review • Finding the least fixed point of any lambda expression • Ordering <Bool x Bool  Bool> • Introduction to Language Design and Assesment University of Virginia CS 655

3. The Story So Far... • We can express any computation using Lambda calculus, a formal system generated by term = variable | term term | (term) |  variable .term and manipulated by simple substitution and reduction rules. • Except, we cheated and used recursive definitions. University of Virginia CS 655

4. Handling Recursive Definitions • We can turn any recursive definition into a non-recursive definition by using a generating function (abstracting out the thing that is recursively defined) • The least fixed point of a generating function is a solution of its corresponding recursive definition. • The least fixed point theorem tells us what the least fixed point is, and gives us an intuition about how to find it, but not a method to find it or know if it exists for a particular function. University of Virginia CS 655

5. Least Fixed Point Theorem If D is a pointed complete partial order, then a continuous function f: D  D has a least fixed point (fixDf) defined by D{ (fnD ) | n 0 } The rest of the story: • Prove this theorem • Do all Lambda expressions have fixed points? • If so, how do we find the fixed point of a Lambda expression? University of Virginia CS 655

6. Proof Sketch • D{ (fnD ) | n 0 } is a fixed point of f Show (f ( D{ (fnD ) | n 0 })) = D{ (fnD ) | n 0 }) • It is the least fixed point of f. If there were another fixed point, it must not be weaker than this one. University of Virginia CS 655

7. Proof Clause 1: Fixed Point ( f ( D{ (fnD ) | n 0 })) = D{ (f (fnD )) | n 0 })) f is continuous so for all chains C in D, f applied to the lub of the chain over D is the lub of (fc) for cC over E. = D{ fn+1D )) | n 0 })) = D{ fnD )) | n 1 })) = D{ fnD )) | n 0 })) since (f 0D) = D University of Virginia CS 655

8. Proof Clause 2: No Lesser Fixed Point • Suppose d’ is a lesser fixed point. • Then: d’ f (D ) f (d’) f is monotonic f (d’) d’d’ is a fixed point f n (D) d’ by induction so (fixDf) = D{ (fnd’) | n 0 } d’ and d’ cannot be a lesser fixed point! D University of Virginia CS 655

9. Do all Lambda terms have fixed points?  F,  X such thatFX = X University of Virginia CS 655

10. Yes! • Proof: LetW =  x.F(xx) andX = WW. X = WW = ( x.F(xx))W   F (WW) = FX University of Virginia CS 655

11. Why of Y? • Y is  f. WW: Y   f. (( x.f (xx))( x. f (xx))) • Y calculates a fixed point (but not necessarily the least fixed point) of any lambda term! • If you’re not convinced, try calculating ((Y fact) n). (PS1, 1e) University of Virginia CS 655

12. How did Smullyan (Mock a Mockingbird) ask the same question? University of Virginia CS 655

13. Is there a Sage Bird? • Given a bird x, there exists somewhere in the forest a bird y of which x is fond: x y = y (To Mock a Mockingbird, p. 74) • Finding the Sage bird : (Ch. 10) University of Virginia CS 655

14. We’re Done! We can completely understand all Lambda terms, and we can describe all computations using Lambda terms. University of Virginia CS 655

15. Rest of the Course • Wimpy programmers want to describe computations using things they can understand more easily than Lambda terms • What are the right/wrong things to provide? • How should/n’t languages provide them? • People want to prove properties about languages that are hard to prove using raw Lambda calculus • Can we describe the meanings of languages in a ways that makes it easier? University of Virginia CS 655

16. History Matters • Learn from past successes and failures • Understand why things are the way they are today (often historical accidents, not “good” reasons) • Rest of Today: Brief History of Programming Language Design • Tuesday: Algol60 University of Virginia CS 655

17. Really Brief History • 50s, 60s: Exciting Time • Invention of: assemblers, compilers, interpreters, first high-level languages, structured programming, abstraction, formal syntax, object-oriented programming, LISP, program verification • 70s, 80s, 90s: Boring Time • Refinement of earlier ideas, better implementations, making theory more practical • A few new/refined ideas: functional languages, data abstraction, concurrent languages, data flow, type theory, etc. University of Virginia CS 655

18. 00s and beyond? • Pessimist’s View: • Like the 70s-90s: the most important concepts have been discovered, and nothing has really changed; slow incremental progress will continue. • Optimist’s View: • New environments (large scale networks, dynamic collections of unpredictable devices) provide new programming challenges (scalability, security, reliability), and new exciting developments will result. First time since 60s that PLs are behind the curve! • Alan Kay: “The best way to predict the future is to invent it.” University of Virginia CS 655

19. UVA’s Info Systems Source: http://www.virginia.edu/year2000/att7-3.htm University of Virginia CS 655

20. What drives programming language design? • Advances in Theory • BNF Grammars  Algol60 • Lambda Calculus  LISP • Type theory  CLU, ML • Changes in computing environment • Analytical engine  first programming system • von Neumann Machines  Procedural Languages • Parallel Machines  Functional Languages • Large, ad hoc networks, physical environments  ??? • Changes in desired programs • Calculating missile trajectories  Assembly • Scientific computations  FORTRAN • Business computations  COBOL, PL/I • Larger programs  Data languages, Components • Even larger programs  ??? • Security requirements  ??? University of Virginia CS 655

21. Less Brief History of PLs • Language Design Really Big Ideas • B0: The First Programs (1830s) • B1: High-level Languages (1950s-) • B2: Structured Languages (1960s-) • B3: Functional Languages (1960s-) • B4: Data Languages (1970s-) • Language Theory Really Big Ideas • L0: Chomsky’s Hierarchy • L1: Formal Syntax (BNF1960) • L2: Formal Semantics (Floyd 67, Scott 71) • L3: Program Verification (Hoare 69, etc.) • L4: Type Theory (60s-2000s) University of Virginia CS 655

22. B0: Ada Byron, Lady Lovelace The First Programmer • Described program to solve Bernoulli equations using Babagge’s Analytical Engine • Store data and program (Jacquard punch cards) • Concepts of: • operator • numerical and symbolic computation (types)! • object-oriented programming! (see quote from Lecture 1) University of Virginia CS 655

23. P1: High-Level Languages • Assemblers, Macro Processors • Pseudo-Code Interpreters • Wilkes, Wheeler & Gill, 1951 (Appendix D) • First Compiler: Grace Murray Hopper, 1950s • Automatic Programming [A-2 compiler, 1953] • Symbolic addresses, decimal numbers • Laning and Zierler’s algebraic system • First algebraic compiler University of Virginia CS 655

24. FORTRAN (Backus, 1954) • Radical idea: computers were more expensive than programmers – if performance suffered, would be failure • Experience with machine code hacking and automatic programming systems convinced programmers efficient code could not be generated automatically • “As far as we were aware, we simply made up the language as we went along. We did not regard language design as a difficult problem, merely a simple prelude to the real problem: designing a compiler which could produce efficient programs.” [Backus, HOPL-I 1978] • Used familiar mathematical notations • Project to design an automatic programming system for the IBM 704, not design a general language “We certainly has no idea that languages almost identical to the one we were working on would be used for more than one IBM computer, not to mention those of other manufacturers. (After all, there were very few computers around then.) [Backus, 1978] University of Virginia CS 655

25. Hopelessly Naïve “In our naïve unawareness of language design problems - of course we knew nothing of many issues which were later thought to be important, e.g., block structure, conditional expressions, type declarations - it seemed to use that once one had the notions of the assignment statement, the subscripted variable, and the DO statement in hand, then the remaining problems of language design were trivial: either their solution was thrust upon one by the need to provide some machine facility such as reading input, or by some programming task which could not be done with existing structures.” [Backus 1978] University of Virginia CS 655

26. Hopelessly Optimistic “Unfortunately we were hopelessly optimistic in 1954 about the problems of debugging FORTRAN programs (thust we find on page 2 of the Report: “Since FORTRAN should virtually eliminate coding and debugging…[!]”) and hence syntactic error checking facilities … were weak.” [Backus 1978] University of Virginia CS 655

27. P2: Structured Languages: Algol(also called: Procedural, Imperative, etc.) • Algol58: captured ideas of FORTRAN in an elegant way – types, conditionals, loops; still limited abstraction from machine • Algol60: • First language designed with principles in mind • Explicit goal: language for publishing algorithms • Introduced: • Formal language syntax (BNF) • Block structure, compound statements, type declarations, variable scopes • Dynamic lifetimes, arrays with dynamic bounds • Notion of actual and formal parameters, call-by-value/call-by-name University of Virginia CS 655

28. Algol’s Successors 1954 FORTRAN 1960 Algol60 Classes CPL Algol68 Committee Simula67 PL/I BCPL Algol-W 1970 Algol68 Smalltalk Pascal C CLU Modula-2 1980 C++ Oberon Modula-3 Java 2000 University of Virginia CS 655

29. P3: Functional Languages • Imperative languages: assign • Functional languages: compose • No state (pure functional languages) • First class functions, closures University of Virginia CS 655

30. Functional Languages FORTRAN 1960 LISP Algol60 ISWIM Mac Lisp 1970 Scheme ML FP 1980 Miranda Common Lisp SML 1990 Haskell ML2000 University of Virginia CS 655

31. FL: Example def f    intsto f:5 (  intsto):5 (f  g):x  f:(g:x) *:(intsto:5) *:<1, 2, 3, 4, 5> 120 University of Virginia CS 655

32. Functional Languages • Claimed Advantages: • Easier to write interpreter for • Easier to learn to program • Easier to reason about programs • Reality: • Hard to get decent performance • Useful for PL research • Especially ML, type systems • Useful for teaching • Especially Scheme University of Virginia CS 655

33. P4: Data Abstraction • FORTRAN: No declarations, types – integer, float, ?; identifier name determined type • Algol60: declarations, types: • Pascal, Algol68: User-defined types, confused about type equivalence • Simula67: added classes to Algol60 • Inheritance • CLU: data abstraction • Methodology for building programs by defining data types • Support for encapsulation (data hiding), iterators • Others: Ada (83), Oberon, Alphard • Smalltalk: object-orientation • Inheritance, subtyping (?), method dispatch • Other O-O languages: C++, Java, Eiffel, Sather, Ada (95), etc. University of Virginia CS 655

34. Data Abstraction Ideas • Type-checking to reduce errors • Early languages: just manipulating bits • Lose expressiveness (especially if statically checked) • Encapsulation to reduce errors, improve maintainability • Specified type used as abstract entity • Subtyping to provide extensibility • Define new properties for a type • Inheritance to reuse code • Use a different types implementation to implement new type University of Virginia CS 655

35. How Should We Assess Languages? • What programs can they express well? • What programs are hard to express? • What tradeoffs have been made between performance, safety, economy, readability, simplicity, consistency, etc.? • What things in the language are confusing, misleading, ambiguous, inconsistent? • Does it have a cool name? University of Virginia CS 655

36. Charge • Read Algol60 Report • Think about questions on manifest as you read it • Troublespots in Algol60 • Can you find any that Knuth missed? • Do you think any of the ones Knuth identifies are unfair? • PS3 out Tuesday • None of the remaining Problem Sets will involve writing code. University of Virginia CS 655