Re: call-with-current-continuation

[Scott Schwartz <schwartz@groucho.cs.psu.edu>]

Paul says:
| i retract what i said earlier about expecting to add call/cc to es.
| the problem that es has with first class continuations is that, in
| a shell, it must be possible to pass a first class value to an exec'ed
| program.  i see no way to do that w/continuations.  that's one of
| the reasons byron and i did not mention first class continuations
| in our paper and why they do not appear on our todo list;  i regret
| that i opened the door to them again, since we had months ago gone
| down the path (in our heads) of trying to figure out what they meant
| in the context of a shell, and concluded that they didn't make too
| much sense.

Most scheme implementations simply print a continuation like
	#[control-point 405248]
which, by design, is not readable.  Is that a fatal decision?  I think
I could live with ``call-cc @ x {echo $x}'' printing something like the
above.

But suppose you printed it instead in a form that was readable by the
shell.  Then you could save the current state of es in a file and read
it back later.  In other words, you'd have an undump facility.  That's
a useful feature, and one that shows that an external representation
for a continuation is a sensible thing to want.  More generally,
doesn't "exec foo" really mean to invoke the continuation stored by the
file foo?  Implementing all this in a nice way might be a pain, but
that's a different issue.

The obvious response is that users would practically never actually use
continuations that way.  The answer, as in scheme, is "so what?"
Continuations are an invaluable abstraction for implementing language
features, even if end users never touch them.