week1: fix markup processing?
authorJim Pryor <profjim@jimpryor.net>
Thu, 16 Sep 2010 03:04:12 +0000 (23:04 -0400)
committerJim Pryor <profjim@jimpryor.net>
Thu, 16 Sep 2010 03:04:12 +0000 (23:04 -0400)
Signed-off-by: Jim Pryor <profjim@jimpryor.net>
test2.mdwn

index 062f6bf..b8627f5 100644 (file)
@@ -146,3 +146,117 @@ because here it's a free variable that's been changed. Nor are they identical to
 because here the second occurrence of `y` is no longer free.
 
 There is plenty of discussion of this, and the fine points of how substitution works, in Hankin and in various of the tutorials we've linked to about the lambda calculus. We expect you have a good intuitive understanding of what to do already, though, even if you're not able to articulate it rigorously.
+
+
+Shorthand
+---------
+
+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
+paren as far the right as possible without creating unbalanced
+parentheses". So:
+
+       (\x (\y (x y)))
+
+can be abbreviated as:
+
+       (\x (\y. x y))
+
+and:
+
+       (\x (\y. (z y) z))
+
+would abbreviate:
+
+       (\x (\y ((z y) z)))
+
+This on the other hand:
+
+       (\x (\y. z y) z)
+
+would abbreviate:
+
+       (\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:
+
+       (\x. x y)
+
+as:
+
+       \x. x y
+
+but you should include the parentheses in:
+
+       (\x. x y) z
+
+and:
+
+       z (\x. x y)
+
+**Merging lambdas** An expression of the form `(\x (\y M))`, or equivalently, `(\x. \y. M)`, can be abbreviated as:
+
+       (\x y. M)
+
+Similarly, `(\x (\y (\z M)))` can be abbreviated as:
+
+       (\x y z. M)
+
+
+Lambda terms represent functions
+--------------------------------
+
+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 x))` duplicates its argument:
+`((\x (x x)) M) ~~> (M M)`
+
+>      `(\x (\y x))` throws away its second argument:
+`(((\x (\y x)) M) N) ~~> M`
+
+and so on.
+
+It is easy to see that distinct lambda expressions can represent the same
+function, considered as a mapping from input to outputs. Obviously:
+
+       (\x x)
+
+and:
+
+       (\z z)
+
+both represent the same function, the identity function. However, we said above that we would be regarding these expressions as synactically equivalent, so they aren't yet really examples of *distinct* lambda expressions representing a single function. However, all three of these are distinct lambda expressions:
+
+       (\y x. y x) (\z z)
+
+       (\x. (\z z) x)
+
+       (\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 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 Monday's meeting (and further discussion is best pursued in person).
+
+
+
+Booleans and pairs
+==================
+
+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 Scheme installed on your
+computer](/how_to_get_the_programming_languages_running_on_your_computer), and
+[get started learning Scheme](/learning_scheme). It will help you test out
+proposed answers to the assignment.
+
+