The grammar we gave for the lambda calculus leads to some verbosity. There are several informal conventions in widespread use, which enable the language to be written more compactly. (If you like, you could instead articulate a formal grammar which incorporates these additional conventions. Instead of showing it to you, we'll leave it as an exercise for those so inclined.)
-Dot notation: dot means "put a left paren here, and put the right
+**Dot notation** Dot means "put a left paren here, and put the right
paren as far the right as possible without creating unbalanced
parentheses". So:
- (\x (\y (xy)))
+ (\x (\y (x y)))
can be abbreviated as:
and:
- (\x \y. (z y) z)
+ (\x (\y. (z y) z))
would abbreviate:
- (\x \y ((z y) z))
+ (\x (\y ((z y) z)))
This on the other hand:
- ((\x \y. (z y) z)
+ (\x (\y. z y) z)
would abbreviate:
- ((\x (\y (z y))) z)
+ (\x (\y (z y)) z)
-Parentheses: outermost parentheses around applications can be dropped. Moreover, applications will associate to the left, so `M N P` will be understood as `((M N) P)`. Finally, you can drop parentheses around abstracts, but not when they're part of an application. So you can abbreviate:
+**Parentheses** Outermost parentheses around applications can be dropped. Moreover, applications will associate to the left, so `M N P` will be understood as `((M N) P)`. Finally, you can drop parentheses around abstracts, but not when they're part of an application. So you can abbreviate:
- (\x x y)
+ (\x. x y)
as:
z (\x. x y)
-Merging lambdas: an expression of the form `(\x (\y M))`, or equivalently, `(\x. \y. M)`, can be abbreviated as:
+**Merging lambdas** An expression of the form `(\x (\y M))`, or equivalently, `(\x. \y. M)`, can be abbreviated as:
(\x y. M)
All (recursively computable) functions can be represented by lambda
terms (the untyped lambda calculus is Turing complete). For some lambda terms, it is easy to see what function they represent:
-(\x x) represents the identity function: given any argument M, this function
-simply returns M: ((\x x) M) ~~> M.
+> `(\x x)` represents the identity function: given any argument `M`, this function
+simply returns `M`: `((\x x) M) ~~> M`.
-(\x (x x)) duplicates its argument:
-((\x (x x)) M) ~~> (M M)
+> `(\x (x x))` duplicates its argument:
+`((\x (x x)) M) ~~> (M M)`
-(\x (\y x)) throws away its second argument:
-(((\x (\y x)) M) N) ~~> M
+> `(\x (\y x))` throws away its second argument:
+`(((\x (\y x)) M) N) ~~> M`
and so on.
(\z z)
-yet when applied to any argument M, all of these will always return M. So they have the same extension. It's also true, though you may not yet be in a position to see, that no other argument can differentiate between them when they're supplied as an argument to it. However, these expressions are all syntactically distinct.
+yet when applied to any argument M, all of these will always return M. So they have the same extension. It's also true, though you may not yet be in a position to see, that no other function can differentiate between them when they're supplied as an argument to it. However, these expressions are all syntactically distinct.
The first two expressions are *convertible*: in particular the first reduces to the second. So they can be regarded as proof-theoretically equivalent even though they're not syntactically identical. However, the proof theory we've given so far doesn't permit you to reduce the second expression to the third. So these lambda expressions are non-equivalent.
-There's an extension of the proof-theory we've presented so far which does permit this further move. And in that extended proof theory, all computable functions with the same extension do turn out to be equivalent (convertible). However, at that point, we still won't be working with the traditional mathematical notion of a function as a set of ordered pairs. One reason is that the latter but not the former permits uncomputable functions. A second reason is that the latter but not the former prohibits functions from applying to themselves. We discussed this some at the end of seminar (and further discussion is best pursued in person).
-
-
+There's an extension of the proof-theory we've presented so far which does permit this further move. And in that extended proof theory, all computable functions with the same extension do turn out to be equivalent (convertible). However, at that point, we still won't be working with the traditional mathematical notion of a function as a set of ordered pairs. One reason is that the latter but not the former permits uncomputable functions. A second reason is that the latter but not the former prohibits functions from applying to themselves. We discussed this some at the end of Monday's meeting (and further discussion is best pursued in person).
Our definition of these is reviewed in [[Assignment1]].
-
+It's possible to do the assignment without using a Scheme interpreter, however you should take this opportunity to [get the software on your computer](/How to get the programming languages running on your computer), and [get started learning about Scheme](/learning_scheme).