On 11/12/2018 4:59 PM, Matthias Felleisen wrote:
> On Nov 12, 2018, at 4:53 PM, George Neuner <gneun...@comcast.net> wrote:
>
> I agree re: *explaining* the behavior in the browser. I don't necessarily agree that either side needs continuations in order to *implement* the behavior. Nor do I agree that persisted continuations are the best way to do it.
>
> I am happy to be persuaded, but I seriously doubt you can do it.
I didn’t say that.
Granted, you didn't say anything about persistence.
What you did say was:
They [web servers] need continuations, because BACK buttons, cloning of TABs
and similar actions force a control flow on interactive web programs that is
easily explained and programmed via first-class continuations (which can be
modeled, among other things, with CPS).
And you are correct about CPS being a good way to explain the behavior.
I'm not convinced that it necessarily is a good way to implement the
behavior. Most developers make a horrible mess of event driven
programming [really any kind of asynchronous programming], and the
callback style with environment passing is particularly error prone.
Most frameworks and "managed" environments exist and are popular not
because they accelerate development for capable programmers - that's
just a lucky byproduct. Rather they are popular because so many
developers simply are incapable of doing useful work without them.
>> Since most PLs do not support first-class continuations, programmers of
interactive web-server plugins to manually encode this flow of control, which is done
via partial CPS conversion.
>
> Examples?
Program any interactive CGI script with an interaction within a loop or
something and you’re forced to invert control flow. That’s a form of CPSing.
Ok, I see where you're going with that. I would argue, though, that the
CPS like behavior is just appearance, and that it is an artifact of
superimposing stateful behavior on a stateless protocol. The underlying
problem of maintaining "session" state is as easily solved from the
client side as from the server side, and doing so would change the
semantics of the exchange from CPS to ordinary call/return.
I would agree that a server-side CPS solution is more efficient if the
amount of state is large. OTOH, in the face of large state, I would
likely not choose to use continuations within the application but rather
would choose to persist state to a database.
YMMV,
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
