This post originated from an RSS feed registered with Ruby Buzz
by Eigen Class.
Original Post: My mind and continuations, callcc seen graphically
Feed Title: Eigenclass
Feed URL: http://feeds.feedburner.com/eigenclass
Feed Description: Ruby stuff --- trying to stay away from triviality.
After writing about the
relative difficulties of callcc and 2ch,
I kept pondering about the nature of the problem with
callcc, or more precisely about the process used to solve problems using continuations. By now, most
(well, many) people know about the CPS transformation, and callcc as a means to get hold
of the implicit continuation ("the rest of the computation"), but we often
have a hard time using continuations: there's a large gap between analytical
comprehension (understanding code which uses callcc) and the ability to
actually synthesize a solution to a problem using callcc.
So I tried to analyze how I solved the
original problem,
deconstructing the process I didn't consciously think about since I had
already internalized it. When trying to solve this, I'm essentially trying to
derive the static representation of the program (code) from the desired
dynamic behavior. I know the solution is going to look like
def open_block(fn)
A1 fh = _open(fn)
A2 yield fh
A3 _close(fh)
end
def open(fn)
B1 # magic
B2 open_block(fn) do |fh|
B3 # magic
end
B4 # magic
end
def close(fh)
C1 # magic
end
APP1 fh = open("foo")
APP2 whatever(fh)
APP3 close(fh)
APP4 puts "DONE"
and I want to find how to complete that code so that at run-time it behaves
as follows