Re: Abominations of nature (was: Features you would like to see)

[Mike Pall <mikelu-0708@...>]

Hi,

Roberto Ierusalimschy wrote:
> [1] Recently there has been some research in Scheme using continuations
> for dynamic sites that would need multi-shot continuations (if the user
> clicked the same button twice). I am still waiting to see how this
> architecture behaves in practice. (There is some debate of what should
> be the "correct" behavior in those situations, from the user point of
> view.)

Someone already tried this with Lua:
  http://lua-users.org/lists/lua-l/2006-01/msg00650.html

I've exchanged a few more messages with Markus Walther after
this. He tried to write a stateful web app using coroutine.clone,
but he didn't seem to be too happy with the results.

Short summary of his findings:
- Upvalues sometimes get in your way, cloning them is tricky.
- There's usually more mutable state in a Lua program than just
  the stack slots. The stack copy is shallow, referenced tables
  or userdatas are not cloned. And it's really hard to specify
  which objects need to be copied and how deep the copy should be.
- Files and databases are tricky. Either you need to add
  versioning, some homegrown undo scheme or (un)limited rollback.
  There's no magic bullet.
- 'Time' is another input which is hard to roll back. :-)

My summary: nice idea and good for some textbook examples. Not
good enough for web apps of any realistic size.

Maybe it works out better with a side-effect free language. Alas,
web programming in these languages seems to be rather unpopular.
Probably _because_ side-effect free programming quickly becomes
unwieldy for this type of apps.

My personal preference for implementing stateful web apps with
rollback functionality would be to explicitly manage the state in
a separate structure and keep a copy for every transaction. If
this turns out to be expensive, then one could keep an undoable
change history at the business object level. This needs less
memory, but is more expensive to roll back (the uncommon case).

Bye,
     Mike