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.
CS655: Programming Languages
University of Virginia
Computer Science
David Evans
http://www.cs.virginia.edu/~evans
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
2
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
3
Handling Recursive Definitions
• We can turn any recursive definition into a nonrecursive 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
4
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
n )|n0}
{
(f
D
D
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
5
Proof Sketch
1.
n  ) | n  0 } is a fixed point of f
{
(f
D
D
Show ( f ( D { (fn D ) | n  0 }))
= D { (fn D ) | n  0 })
2. 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
6
Proof Clause 1: Fixed Point
n  ) | n  0 }))
{
(f
D
D
n  )) | n  0 }))
{
(f
(f
D
D
(f(
=
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.
=
=
=
22 Feb 2000
n+1  )) | n  0 }))
{
f
D
D
n  )) | n  1 }))
{
f
D
D
n  )) | n  0 })) since (f 0  ) = 
{
f
D
D
D
D
University of Virginia CS 655
7
Proof Clause 2: No Lesser
Fixed Point
• Suppose d’ is a lesser fixed point.
• Then:
D d’
f ( D )
f (d’)
f is monotonic
f (d’ )
f n (D)
d’
d’
d’ is a fixed point
by induction
so (fixD f) = D { (fn d’ ) | n  0 } d’
and d’ cannot be a lesser fixed point!
22 Feb 2000
University of Virginia CS 655
8
Do all Lambda terms have
fixed points?
 F,  X  such that FX = X
22 Feb 2000
University of Virginia CS 655
9
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
10
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
11
How did Smullyan (Mock a
Mockingbird) ask the same
question?
22 Feb 2000
University of Virginia CS 655
12
Is there a Sage Bird?
• Given a bird x, there exists somewhere
in the forest a bird y of which x is fond:
xy=y
(To Mock a Mockingbird, p. 74)
• Finding the Sage bird : (Ch. 10)
22 Feb 2000
University of Virginia CS 655
13
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
14
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
15
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
16
Really Brief History
• 50s, 60s: Exciting Time
– Invention of: assemblers, compilers, interpreters,
first high-level languages, structured
programming, abstraction, formal syntax, objectoriented 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
17
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
18
UVA’s Info Systems
Language
COBOL
Mantis
Clipper 5
PDL (DBS 4GL)
Assembler
SAS
C
Lines of Code
3,630,650
505,016
224,420
196,697
53,387
52,609
5,000
Source: http://www.virginia.edu/year2000/att7-3.htm
22 Feb 2000
University of Virginia CS 655
19
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
20
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
21
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
22
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
23
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
24
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
25
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
26
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-byvalue/call-by-name
22 Feb 2000
University of Virginia CS 655
27
Algol’s Successors
FORTRAN
1954
1960
Algol60
Classes
CPL
BCPL
C
Simula67
PL/I
Algol-W
Algol68
Pascal CLU Smalltalk
1970
Modula-2
C++
Oberon
Modula-3
Java
22 Feb 2000
1980
2000
University of Virginia CS 655
28
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
29
Functional Languages
FORTRAN
1960
LISP
Algol60
ISWIM
ML
Mac Lisp
FP
1970
Scheme
1980
Miranda
Common Lisp
SML
Haskell
1990
ML2000
22 Feb 2000
University of Virginia CS 655
30
FL: Example
def f    intsto
f:5
(  intsto):5
*:(intsto:5)
*:<1, 2, 3, 4, 5>
120
22 Feb 2000
(f  g):x  f:(g:x)
University of Virginia CS 655
31
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
32
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
33
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
34
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
35
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
36