1. David Evans http://www.cs.virginia.edu/~evans
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.
Background
just got here last week
finished degree at MIT week before
Philosophy of advising students
don’t come to grad school to implement someone else’s idea
can get paid more to do that in industry
learn to be a researcher
important part of that is deciding what problems and ideas are worth spending time on
grad students should have their own project
looking for students who can come up with their own ideas for research
will take good students interested in things I’m interested in – systems, programming languages & compilers, security
rest of talk – give you a flavor of the kinds of things I am interested in
meant to give you ideas (hopefully even inspiration!) but not meant to suggest what you should work on
CS655: Programming Languages
University of Virginia
Computer Science
David Evans

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

3. University of Virginia CS 655
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.
22 Feb 2000
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.
22 Feb 2000
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 (fixD f) 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?
22 Feb 2000
University of Virginia CS 655

6. University of Virginia CS 655
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.
22 Feb 2000
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 (f c) 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
22 Feb 2000
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 (fixD f) = D { (fn d’ ) | n  0 } d’
and d’ cannot be a lesser fixed point! D
22 Feb 2000
University of Virginia CS 655

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

10. University of Virginia CS 655
Yes!
Proof:
Let W =  x.F(xx) and X = WW.
X = WW = ( x.F(xx))W
  F (WW) = FX
22 Feb 2000
University of Virginia CS 655

11. University of Virginia CS 655
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)
22 Feb 2000
University of Virginia CS 655

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

13. University of Virginia CS 655
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)
22 Feb 2000
University of Virginia CS 655

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

15. University of Virginia CS 655
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?
22 Feb 2000
University of Virginia CS 655

16. University of Virginia CS 655
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
22 Feb 2000
University of Virginia CS 655

17. University of Virginia CS 655
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.
22 Feb 2000
University of Virginia CS 655

18. University of Virginia CS 655
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.”
22 Feb 2000
University of Virginia CS 655

19. University of Virginia CS 655
UVA’s Info Systems
Language
Lines of Code
COBOL
3,630,650
Mantis
505,016
Clipper 5
224,420
PDL (DBS 4GL)
196,697
Assembler
53,387
SAS
52,609 C
5,000
Source:
22 Feb 2000
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  ???
22 Feb 2000
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)
22 Feb 2000
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)
22 Feb 2000
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
22 Feb 2000
University of Virginia CS 655

24. University of Virginia CS 655
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]
22 Feb 2000
University of Virginia CS 655

25. University of Virginia CS 655
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]
22 Feb 2000
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]
22 Feb 2000
University of Virginia CS 655

27. University of Virginia CS 655
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
22 Feb 2000
University of Virginia CS 655

28. University of Virginia CS 655
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
22 Feb 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
22 Feb 2000
University of Virginia CS 655

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

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

32. University of Virginia CS 655
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
22 Feb 2000
University of Virginia CS 655

33. University of Virginia CS 655
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.
22 Feb 2000
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
22 Feb 2000
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?
22 Feb 2000
University of Virginia CS 655

36. University of Virginia CS 655
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.
22 Feb 2000
University of Virginia CS 655