How do I convert these procedures in Scheme to CPS form?
(lambda (x y) ((x x) y))
(lambda (x) (lambda (f) (f (lambda (y) (((x x) f) y))))
((lambda (x) (x x) (lambda (x) (x x))
*This is not any homework!
How do I convert these procedures in Scheme to CPS form?
(lambda (x y)
((x x) y))
(lambda (x)
(lambda (f)
(f (lambda (y)
(((x x) f) y))))
((lambda (x) (x x)
(lambda (x) (x x))
*This is not any homework!
You need to choose to what level you need/want to CPS-transform.
If you just want (lambda (x y) ((x x) y))
in continuation-passing(CP) style, then (lambda (k x y) (k ((x x) y)))
will do fine.
If you want its arguments to be treated as being in CP style too, then you need a little more.
Suppose first that only the second argument (y
) is in CP form and is thus really something like (lambda (k) (k y0))
and so needs to be called with some continuation to extract its value, then you would need:
(lambda (k x y)
(y (lambda (y0) (k ((x x) y0)) )) )
Finally assume that both x
and y
are in CP style. Then you would need something like:
(lambda (k x y)
(x (lambda (x0)
(x (lambda (x1)
(y (lambda (y0)
(k ((x0 x1) y0)) ))))
Here you have the freedom to reorder the calls to x
and y
. Or maybe you only need one call to x
, because you know its value does not depend on the continuation it is called with. For example:
(lambda (k x y)
(y (lambda (y0)
(x (lambda (x0)
(k ((x0 x0) y0)) ))))
The other expressions you asked about can be transformed similarly.
See Programming Languages, Application and Interpretation, starting around Chapter 15. Chapter 18 talks about how to do it automatically, but if you're not familiar with thinking about expressing a function that does "what to do next", you'll probably want to try the finger exercises first.
Don't have someone do it for you: you'll really want to understand the process and be able to do it by hand, independent of Scheme or otherwise. It comes up especially in Asynchronous JavaScript web programming, where you really have no choice but to do the transform.
In the CPS transform, all non-primitive functions need to now consume a function that represents "what-to-do-next". That includes all lambdas. Symmetrically, any application of a non-primitive function needs to provide a "what-to-do-next" function, and stuff the rest of the computation in that function.
So if we had a program to compute a triangle's hypothenuse:
and if we state that the only primitive applications here are
*
,+
, andsqrt
, then all the other function definitions and function calls need to be translated, like this:The last expression shows that you end up having to compute "inside-out", and that the transformation is pervasive: all lambdas in the original source program end up needing to take an additional argument, and all non-primitive applications need to stuff "what-to-do-next" as that argument.
Take a close look at section 17.2 of the cited book: it covers this, as well as 17.5, which talks about why you need to touch ALL the lambdas in the source program, so that the higher-order case works too.
As another example of the transform, applied for a higher-order case, let's say that we have:
Then the translation of something like this is:
... because that lambda's just a value that can be passed to
k1
. But of course, the translation needs to run through the lambda as well.We must first do the inner call to
f
withx
(and remember that all non-primitive function applications need to pass an appropriate "what-to-do-next!"):... take that value and apply it again to f...
... and finally return that value to
k2
: