One use case in the back of my mind dealing with the Actor model was with the web. Actor's communicate via message passing only, and in many cases this is asynchronous message passing. This is basically the same thing as sending and receiving information via HTTP. Although I admit I haven't done much web work in awhile... I think the Seaside framework uses continuations in this way. Anyway, when a user is navigating a website, if they have a few forms to fill in, it can possibly become hair keeping track of that user's session. I'd imagine the standard way is whenever the user inserts information into a form and transfers to another page in the site, some sort of session object or state object is updated with this information, and any further interactions with them are tracked this way. This can cause problems when they use their back button, or just copy the web address to open a new tab (perhaps to navigate to a different part of the site.) Message passing/continuation passing style, in this case, would basically - as I understand it - code up each specific page as an island, expecting all user information to be given in its arguments and not making any look ups to any sort of session or state object for the user. Jumping to a new web page then is nothing more than 'continue' to another function call, whilst passing all needed and gathered information through function arguments alone. The backbutton and clones work in a simpler fashion because there is no more persistent state between page visits, all state is transferred at the boundary right where the 'continue' happens. Like many have mentioned, you can probably do the same thing, once again by having some sort of trampoline outside of each page handler figuring out where to send the use next, and transferring some sort of global state id along with each user, I just imagine that since web programming is one of the major uses of Python, this sort of thing has to get pretty tiring. I realize I'm still speaking a little too high level and in generalities, but if someone would like I could take some time and try and drive the above example into actual code. On Sun, May 3, 2009 at 5:13 PM, Mike Meyer wrote:

On Sun, 3 May 2009 15:22:55 -0600 Adam Olsen wrote:

...

In contrast, we have the before with trampolines:

def a():     return (b, arg1, arg2)

and the after:

def a():     continue b(arg1, arg2)

But that's only one end of the code involved in the trampoline. The other end goes from:

     func = a      results = args      while func:         results = func(*results)         func = results[0]         results = results[1]

or (by tweaking your return code to "return b, (arg1, arg2)") the less transparent:

     results = a, args      while results[0]:         results = apply(*results)      results = results[1]

to:

     results = a(args)

That looks every bit as significant as the change you get from a list comprehension to me - and these are simplified by ignoring keyword args.

But we still need a use case.

...

Sure, it's prettier to look like a function call, but you're disguising the fact that you're not calling it as a function right now.  You're also disguising that you're returning from this function.

Actually, I consider that a problem with the proposed syntax. I'd prefer to make the distinction explicit.

                   http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org