[Python-ideas] A Continuations Compromise in Python

[John Graham]

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 <mwm at mired.org> wrote:
> On Sun, 3 May 2009 15:22:55 -0600
> Adam Olsen <rhamph at gmail.com> 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.
>
>       <mike
> --
> Mike Meyer <mwm at mired.org>              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
>