What we did in Monday's seminar
--------------------------------
+===============================
We start with a simulation of semantic composition:
This is shorthand for the same thing. Just trust me on that.
What's going on here?
-=====================
+---------------------
`(cons M N)` is a request to build an ordered pair out of the values M and N.
Scheme displays that pair as `'(M . N)` You can't write `(M . N)` yourself and expect Scheme to understand that you're talking about this pair. If you tried, to, Scheme would think you're trying to apply the function M to some arguments, which you're not, and also
We start by defining `damn` as a "thunk" that when applied to zero arguments returns a trivial adjectival meaning, which we'll designate with the primitive symbol `'id`.
What's a "thunk"?
-=================
+-----------------
Remember, in Scheme you can have functions that take one value, and also functions that take two values, and also functions that take zero values. The last ones are called "thunks." The thunk is not identical to the value it returns. For instance:
(lambda () 3)
-is a thunk that returns the integer 3. If we bind the variable `t` to that thunk, then `t` is a function (Scheme will display it as`#<procedure>`)
+is a thunk that returns the integer 3. If we bind the variable `t` to that thunk, then `t` is a function (Scheme will display it as
`#<procedure>`)
not an integer. Whereas `(t)` is an integer not a function.
-There's no reason yet on hand for us to make `damn` be a thunk. For present purposes, we could also just define `damn` to be the symbol `'id`. But what we're going to go on to do does require us to make `damn` be a thunk. The reason for that is to postpone the evaluation of some expressions until the continuations we want to operate on are in place.
-
-So for uniformity we're going to make `damn` be a thunk right from the beginning.
+There's no reason yet on hand for us to make `damn` be a thunk. For present purposes, we could also just define `damn` to be the symbol `'id`. But what we're going to go on to do does require us to make `damn` be a thunk. The reason for that is to postpone the evaluation of some expressions until the continuations we want to operate on are in place. So for uniformity we're going to make `damn` be a thunk right from the beginning.
As we said, `damn` starts as a thunk that returns a trivial adjectival meaning `'id`:
((the . man) . (read . (the . (id . book))))
-If you try this yourself, you may see instead:
-
- '((the . man) read the id . book)
+---or an equivalent shorthand. (I'm now going to stop saying this.)
+How to get some affective meaning into damn?
+--------------------------------------------
-Now we want to get some affective meaning into damn. So we might try:
+We might try:
(define damn (lambda () 'bad))
and we said at the outset that the context `(the . ( ... . book))` shouldn't need to know how to interact with affective meanings. That's precisely the problem we're trying to solve.
+Let's use continuations
+-----------------------
+
A promising way to handle this is with **continuations**, which you will get much more familiar with as this seminar progresses. Don't worry about not understanding what's going on quite yet. This is just an advertisement that's supposed to provoke your imagination.
Chris and others have applied the apparatus of continuations to the analysis of expressives in the paper cited at the top. For a simple in-class demonstration, we tried to do the following.
Yay! The affective meaning has jumped out of the compositional evaluation of the main sentence, and the context `(the . (... . book))` only has to deal with the trivial adjectival meaning `'id`.
-**But.** As came out in discussion, the `print` we're using here already constitutes a kind of side-effect mechanism of its own. If you say:
+
+But
+---
+
+As came out in discussion, the `print` we're using here already constitutes a kind of side-effect mechanism of its own. If you say:
(define three-thunk (lambda () (print "hi") 3))
So a better demonstration would do without any device like `print` that already incorporates continuations implicitly. Any continuation-manipulation should be fully explicit.
+
+Can we do better?
+-----------------
+
Instead of representing the side-issue affective contribution by printing "bad", let's instead try to build a pair of side-effect contributions and at-issue assertion. Then what we want would be something like:
((side-effect . bad) . ((the . man) . (read . (the . (id . book)))))
However, this doesn't work. The reason is that an undelimited continuation represents the future of the evaluation of `(damn)` *until the end of the computation*. So when `'id` is supplied to `k`, we go back to building the at-issue tree until we're finished *and that's the end of the computation*. We never get to go back and evaluate the context `(cons (cons 'side-effect 'bad) ...)`.
+
+With undelimited continuations
+------------------------------
+
The straightforward way to fix this is to use, not undelimited continuations, but instead a more powerful apparatus called "delimited continuations." These too will be explained in due course, don't expect to understand all this now.
A delimited continuation is captured not by using `call/cc`, but instead by using a variety of other operators. We'll use the operator `shift`. This substitutes for `call/cc`. The syntax in Scheme is slightly different. Whereas we wrote:
So that's the straightforward way of repairing the strategy we used in class, without using `print`. We also have to switch to using delimited continuations.
-Ken Shan, however, pointed out a lovely way to get to the same end-point still using only undelimited continuations (`call/cc`).
+Ken's proposal
+--------------
+
+Ken Shan pointed out a lovely way to get to the same end-point still using only undelimited continuations (`call/cc`).
(let ((pragma
; An ordered pair whose first component is the assertion