Class 19: Another Perspective: FP
Held Monday, March 8
- Cool math convocation this Thursday. Be there.
- Do you want another homework assignment before the next test? The
assignment would be on the semantics of Scheme. (Yes, there will
be at least one exam question on the semantics of Scheme.)
- Email me. If at least half the class wants an assignment, I'll
have one ready tomorrow morning.
- Assignment 3 due.
- In case you hadn't figured it out already, you should have the
Backus paper with you this week.
- Some initial questions:
- What is the ``von Neumann bottleneck''?
- Why is there a transpose in the functional
- What is a functional form?
- FP is a functional programming language designed by John Backus
- Unlike Scheme and other such languages, it has no lambda abstractions
and no built-in lists (although it does have built-in vectors, matrices,
- Backus designed FP to rectify some of the problems he saw with
- Too much emphasis on ``low-level'' issues, particularly moving data
to and from the store.
- Hard to prove things about programs (e.g., that two programs are equiv.)
[No, this is not a violation of the halting problem]
- These two issues make it hard to parallelize programs.
- What do we need as we design a programming language?
- A simple language
- ``High level''
- Deal with more than bytes (including as return values for functions)
- Powerful and expressive enough that programmers can build useful
new structures that normally have to be included in languages.
- He designed a category of languages, and talked about a particular instance.
- We usually refer to that instance (and slight variants) as FP.
- FP consists of:
- Objects (the things which we operate on)
- Functions (the things that operate)
- Application (of functions to objects)
- Functional forms (higher-order functions, in some sense)
- Definitions (of user defined functions, typically using
- Objects are
- Symbolic values
- Boolean values
- Bottom (undefined)
- Sequences are heterogeneous
- In his paper, Backus defines a number of primitive functions in FP.
- Note that these definitions are done using a separate language.
- In effect, these definitions are the formal semantics of FP.
- Programmers write different types of definitions (we'll see those later)
- We need a language for the ``is defined as'' part.
- It's fairly simple, looks like math, and includes a conditional.
- The conditional is written as
test -> true-part; false-part
- This has meaning
``If the test holds, then the value of this expression is the value
of the true part. If the test fails to hold, then the value of this
expression is the value of the false part. ''
- Note that all the functions are bottom-preserving: if you have
a value that can't be computed, then applying a function to that value
still gives you something that can't be computed.
- There are a number of basic functions in FP. You can follow along in the
- When writing your own functions in FP, you can not use the abstract
definitions given for the built-in functions. Rather, you define
functions in terms of other functions, using the Def syntax.
- Note that there are no arguments to functions!
- We'll just do a few to get you used to reading the definitions.
- selectors (which you may recall from the
formal semantics of Scheme).
n : S selects the nth element of sequence S
1:x == x=<x1,...,xn>
-> x1; bottom
s:x == x=<x1,...,xn> &
n >= s -> xs; bottom
- also right selectors
- tail (a lot like cdr, and the ``drop''
in the formal semantics of Scheme)
tl:x takes the tail of a list
tl:x == x=<x1> -> nil ;
n >= 2 -> <x2,...,xn>
- also right tail
- atom (for ``type-checking'')
- equals (note that it has only one argument)
- null (another form of type checking)
- Boolean opeartions
- iota (ints from 1 to n)
- not in the paper, but in almost every implementation
- Created Tuesday, January 19, 1999 as a blank outline.
- Filled in the details (such as they are) on Monday, March 8, 1999.
(Some details based on notes from an old class I taught at Dartmouth.)