<p dir="ltr">And, predictably, that gave me a headache... :-)<br></p>
<p dir="ltr">--Guido van Rossum (sent from Android phone)</p>
<div class="gmail_quote">On Oct 22, 2012 4:49 PM, "Greg Ewing" <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Guido van Rossum wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Oct 22, 2012 at 3:33 PM, Greg Ewing <<a href="mailto:greg.ewing@canterbury.ac.nz" target="_blank">greg.ewing@canterbury.ac.nz</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It has a broader meaning than the one in Scheme; essentially<br>
it's a synonym for "callback".<br>
</blockquote>
<br>
(Off-topic:) But does that meaning apply to Scheme? If so, I wish<br>
someone would have told me 15 years ago...<br>
</blockquote>
<br>
It does, in the sense that a continuation appears to the<br>
Scheme programmer as a callable object.<br>
<br>
The connection goes deeper as well. There's a style of<br>
programming called "continuation-passing style", in which<br>
nothing ever returns -- every function is passed another<br>
function to be called with its result. In a language such<br>
as Scheme that supports tail calls, you can use this style<br>
extensively without fear of overflowing the call stack.<br>
<br>
You're using this style whenever you chain callbacks<br>
together using Futures or Deferreds. The callbacks don't<br>
return values; instead, each callback arranges for another<br>
callback to be called, passing it the result.<br>
<br>
This is also the way monadic I/O works in Haskell. None<br>
of the I/O functions ever return, they just call another<br>
function and pass it the result. A combination of currying<br>
and syntactic sugar is used to hide the fact that you're<br>
passing callbacks -- aka continuations -- around all<br>
over the place.<br>
<br>
Now, it turns out that you can define all the semantics<br>
of Scheme, including its continuations, by writing a Scheme<br>
interpreter in Scheme that doesn't itself use Scheme<br>
continuations. You do it by writing the whole interpereter<br>
in continuation-passing style, and it becomes clear that<br>
at that level, the "continuations" are just ordinary<br>
functions, relying on lexical scoping to capture all of the<br>
necessary state.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I guess that was just Steve showing off. :-)<br>
</blockquote>
<br>
Not really -- to someone with a Scheme or FP background,<br>
it's near-impossible to look at something like a chain<br>
of Deferred callbacks without the word "continuation"<br>
springing to mind. I agree that it's not helpful to<br>
anyone without such a background, however.<br>
<br>
-- <br>
Greg<br>
<br>
______________________________<u></u>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/<u></u>mailman/listinfo/python-ideas</a><br>
</blockquote></div>