Talk:Continuation

Perl re-added

Piet Delport removed perl with a bogus explanation (the entry refered to Coro, not Coro::Cont, and both Coro and Coro::Cont provide continuations and not just generators).

Delegates as continuations

I really would have to question whether C# supports continuations in any meaningful form. A C# delegate is little more than a function pointer. (See [1]) MAllerton 19:14, 18 July 2005 (UTC)

The use of delegates as continutations in C# comes from their use in callbacks in asynchronouus invocations.--Carl Hewitt 20:12, 18 July 2005 (UTC)

As usual you're not answering the question. Function pointers can't be full blown continuations by the simple fact that they don't save any part of the state/stack. -- Koffieyahoo 10:38, 20 July 2005 (UTC)

I suggest that you read the documentation on the use of delegates for asynchronous invocation.--Carl Hewitt 16:17, 20 July 2005 (UTC)

Can you provide me with a reference? -- Koffieyahoo 08:50, 21 July 2005 (UTC)

See the following for an example.--Carl Hewitt 21:08, 21 July 2005 (UTC)

Asynchronous Web Services

This describes a call-back mechanism, which only saves state by virtue of all relevant data being contained in an object. Hence, this should not be classified as a continuation (the system itself doesn't save any state). So, a more relevant reference is required to convince me that delegates are continuations. --Koffieyahoo 10:04, 4 August 2005 (UTC)

Moreover so, I'm pretty sure the CLR doesn't allow continuations because the stack context (like in the jvm) can't be reified. Wouter Lievens 10:38, 4 August 2005 (UTC)

What do you mean by a continuation?--Carl Hewitt 10:58, 4 August 2005 (UTC)

The article is pretty clear about what a continuation is. -- Karada 11:01, 4 August 2005 (UTC)

In that case, I don't see a problem with using a delegate for such continuations because it has access to the stack frame.--Carl Hewitt 11:06, 4 August 2005 (UTC)

The idea is that the stack frame is saved, being able to access it is not enough. -- Koffieyahoo 12:11, 19 August 2005 (UTC)

I removed the misleading reference to "state" from the beginning of the article. It now reads as follows:

"In computing, a continuation is a representation of an execution point (for example, the instruction pointer and stack frame). Many languages have constructs that allow a programmer to obtain a pointer to a continuation, and then to resume execution using the pointer at a later point in time."

--Carl Hewitt 15:52, 19 August 2005 (UTC)

I don't see how this solves the problem with C#, in that case it's still just a pointer, and that plainly isn't enough for execution to resume. -- Koffieyahoo 09:31, 23 August 2005 (UTC)

Please see the documentation on delegates.--Carl Hewitt 13:14, 23 August 2005 (UTC)

I've done that, and what I see is a function pointer, which doesn't suffice (no stack frame, no intruction pointer). So please eleborate here. -- Koffieyahoo 15:01, 23 August 2005 (UTC)

C# has delegates which are not the same as the function pointers in Java.--Carl Hewitt 21:57, 23 August 2005 (UTC)

Java doesn't have function pointers. Anyway, C# doesn't even have closures, and you can't have continuations without closures. C#s delegates (which work more or less like function objects in C++) just don't suffice. Cadr 22:15, 23 August 2005 (UTC)

Sorry, I meant say that C# has delegates which are not the same as the function pointers in C++.--Carl Hewitt 22:39, 23 August 2005 (UTC)

Okay, so basically there are four people who think that C# does not have continuations and only one thinks that C# has continuations (based on arguments refuted by the other persons). So, I'm removing it from the article. If we want to add it back we should discuss this here first! -- Koffieyahoo 13:29, 24 August 2005 (UTC)

You can't remove it without quoting from the reference to the documentation on delegates.--Carl Hewitt 14:27, 24 August 2005 (UTC)

I've been trying to find an appropriate reference, e.g., by asking you for one. And nothing has turned up, so I simply don't think you're right. Provide me with a reference before you add it back. Every piece of documentation you and others have come up with shows that delegates are not continuations. -- Koffieyahoo 14:56, 24 August 2005 (UTC)

I provided you with the following reference Asynchronous Web Services

You must quote from this document and possibly from other authorities.--Carl Hewitt 18:45, 24 August 2005 (UTC)

Erm, no. The burden of proof is on you in this case. Are we to find documentation for all the other 1000s of programming languages which don't have continuations? What's so notable about C# that it deserves such special treatment? Cadr 20:03, 24 August 2005 (UTC)

A specific citation has been provided above. Have you read it?--Carl Hewitt 20:37, 24 August 2005 (UTC)

That reference doesn't say anything about continuations, so I don't see what it's meant to prove. I've only skimmed the article, but asynchronous callbacks are not at all the same thing as continuations. Can you show us an example program in C# which shows how you would implement call/cc or some equivalent operation in C#? Cadr 23:00, 24 August 2005 (UTC)

The refernce contains a program that performs this.EndInvoke(asyncResult) which resumes execution of the continuation (stack frame).--Carl Hewitt 23:20, 24 August 2005 (UTC)

The reference does not contain a program that performs a call to EndInvoke (it just mentions EndInvoke breifly without really explaining what it does). In any case, suspeding a thread of execution and then resuming it is not equivalent to a continuation. For one thing, a continuation can be called multiple times with identical results (assuming it has no side effects).Cadr 23:58, 24 August 2005 (UTC)

The refernce contains a program that performs this.EndInvoke(asyncResult) which resumes execution of the continuation (stack frame).--Carl Hewitt 04:35, 25 August 2005 (UTC)

As far as I understand it this.EndInvoke(asyncResult) resumes based on solely on the state of the object, which is subject to change between the creation of the delegate and its invocation. Hence, I still don't believe delegates are full-blown continuations. Anyway it was removed from the article. -- Koffieyahoo 09:09, 6 September 2005 (UTC)

C# delegates definitely do NOT constitute continuations. They can be used with lots of multithreaded trickery to IMPLEMENT a continuation library, but they themselves are not continuations. However, C# does have the "yield return" and "yield break" keywords which ARE directly able to provide continuation-like behavior. C# delegates, though, have absolutely nothing to do with it. For anyone that disagrees, please provide a code example. Here is a code example of continuations with yeild return:

IEnumerable CF(int max) {
   for(int i=0; i < max; ++i ) {
      yield return i;
   }
}

If C# indeed suports other sorts of continuations, it should be trivial for one to provide a delegate-based example.

The article continuation states that there is more than one kind of continuation as follows:

Kinds of continuations

Support for continuations varies widely. A programming language supports re-invocable continuations if a continuation may be invoked repeatedly (even after it has already returned1). Re-invocable continuations were introduced by Peter Landin using his J (for Jump) operator that could perform a nonlocal goto into the middle of a procedure invocation. Re-invocable continutations have also been called "re-entrant" in the MzScheme programming language. However this use of the term "re-entrant" is too easily confused with its use in discussions of multitasking.

At one time Sussman and McDermott thouught that using re-invocable continutations (which they called "Hairy Contol Structure") was the solution to the AI control structure problems that had originated in Planner. Carl Hewitt et. al. developed message passing as an alternative solution in the Actor model. Guy Steele and Gerry Sussman then developed in the continuations in Scheme in their attempt to understand the Actor model.

A more limited kind is the escape continuation that may be used to escape the current context to a surrounding one. Many languages which do not explicitly support continuations support exception handling, which is equivalent to escape continuations and can be used for the same purposes. C's setjmp and longjmp are also equivalent: they can only be used to unwind the stack. Escape continuations can also be used to implement tail-call optimization.

--Carl Hewitt 04:30, 25 August 2005 (UTC)

OK, then why not use exception handling in C# to demonstrate it's level of support for continuations instead of this more obscure stuff? Cadr 19:24, 26 August 2005 (UTC)

Anynchronous invocation is a more interesting use of continuations in C# than exception handling.--Carl Hewitt 00:58, 27 August 2005 (UTC)

When people say "support for continuations" they usually mean full continuations, since this is what distinguishes a notable subset of languages (e.g. Scheme) from the vast bulk of languages. "Escape continuations" aka exceptions are not remarkable, since most high-level languages support them. --FOo 21:42, 26 August 2005 (UTC)

In a encyclopedia article, it is useful to discuss the full range of continuations. What do you mean by a full continuation?--Carl Hewitt 00:58, 27 August 2005 (UTC)

A full continuation can be invoked multiple times. Languages which are said to "support" continuations are usually expected to have something like call-with-current-continuation, or perhaps as an alternative an easy method of writing programs in continuation passing style (I'm thinking of Haskell here). Really, any language can be said to support continuations. After all, if you are a masochist, you can write a C program in CPS and then play around with continuations as you please. Indeed, it's not particularly difficult to write CPS C code automatically, as Scheme compilers such as Chicken demonstrate. Asking whether a language supports continuations is a bit like asking whether it supports object oriented programming. The real question is "does the language support continuation passing style without a lot of hard work and/or the use of obscure language features?"

One more thing, Carl. Are you saying that asynchronous method invocation doesn't offer anything closer to full continuations than the exception mechanism? If so, it would be far better to use the exception mechanism as an example since it's much easier to understand (regardless of how interesting it may or may not be). Cadr 00:22, 3 September 2005 (UTC)

On reconsideration, I now beleive that it is better to remove the C# delegates from the article so I have done so.--Carl Hewitt 01:12, 3 September 2005 (UTC)

Python continuations?

Python doesn't have an explicit "continuation object" which you can store and reclaim state from/to. However, in the current version of Python (2.4) you have "generators"; they are resumable functions which return a value using the "yield" statement. Does that qualify as a continuation? See [[2]] for examples of use.--Larry Hastings 16:46, 15 March 2006 (UTC)

Generators don't qualify as continuations. Tim Peters wrote a wonderful mini-essay on how Python generators, coroutines, and continuations relate to each other, but the short version is:

• Generators represent a single frozen stack frame, while continuations represent a complete call stack.
• A generator's frame gets resumed on top of its caller, and returns back to it, while a continuation completely replaces its caller's stack (and thus cannot "return").
• You cannot capture or resume previous states of a generator, but you can invoke continuations from any time in the past, whenever you like, as many times as you like.

--Piet Delport 16:45, 16 March 2006 (UTC)

Example

I've added the scheme example from Tim Peters's linked posting. This article (an continuations in general) didn't make any sense until I read a concrete example. —The preceding unsigned comment was added by 14:38, 10 July 2006 (talk • contribs) Gene Thomas.

Use of closures and continuation-passing style to implement call/cc

The article currently contains the following paragraph:

In any language which supports anonymous closures, it is possible to write programs in continuation passing style and manually implement call/cc. This is a particularly common strategy in Haskell, where it is easy to construct a "continuation passing monad".

I do not see why the closures would have to be anonymous as it is obviously possible (albeit tedious) to name all continuations. Also, while you can program using CPS in every language with closures, I am not sure whether this really is practical without guaranteed tail-call elimination, so I think this should at least be mentioned. — Tobias Bergemann 08:32, 15 August 2006 (UTC)

Right, the naming of closures is completely orthogonal.

I don't think it's necessary to mention tail-call elimination, though. In strict languages, it's very simple to prevent inefficient tail calls using a trampoline, and in pure, lazy languages like Haskell, the very notion of tail-call elimination becomes ill-defined (since there isn't really any conventional, implicit call stack to do the elimination on). --Piet Delport 22:32, 16 August 2006 (UTC)

Don't start with Scheme!!

I don't think the initial examples should be in Scheme. I don't think this is the best for understanding for the vast majority of programmers. I myself program for a living, and I totally balked at the Scheme intro, not grasping one single thing of what it tries to explain (The same goes for Closure (computer science), using Lisp). If one look at Coroutines, this starts off with some nice pseudocode, immediately understandable for anyone having the slightest interest in computer languages, adaptable to one's preferred universe. — Preceding unsigned comment added by 84.208.115.107 (talk • contribs)

I fully disagree with that. As a self-taught, working programmer who started with C, if you want to understand these sorts of topics (which you should), you need to do your homework & learn the vernaculars. (Or...er...the opposite of the vernacular, I suppose.) While there may not be a lingua franca of computer science, Scheme is one of those languages that is close. --Malirath 21:00, 11 September 2006 (UTC)

Hear, hear. --Piet Delport 22:30, 11 September 2006 (UTC)

It also strikes me that pseudocode means that nobody except the author can be certain what it means. Sticking to R*RS Scheme, however, ensures that an example is as clear as it can be. Nigh anyone who can read Wikipedia can read the standard. --Malirath 02:35, 18 September 2006 (UTC)

Although I am not a Scheme user (I studied it years ago, but for work, I write mostly in Python) I think that ideas like this are better illustrated with Scheme or Lisp than with C-ish languages. A Lisp-oid language shows explicitly where the lexical contours are. In a subject such as continuations, this is essential. --FOo 03:03, 18 September 2006 (UTC)