Re: async 1.0

[John Wiegley]

>>>>> Sivaram Neelakantan <address@hidden> writes:

> As a lowly user of Emacs, is this going to get into the main branch as I
> seem to be doing a lot of stuff in Emacs that makes the wait icon a regular
> screen feature?

Getting async.el into the main branch can happen next week, if Stefan and RMS
approve.  But modifying Emacs packages to take advantage of asnynchronicity
would require a lot more time and testing.

One thing that would make async.el _incredibly_ useful would be a `call/cc'
function in Emacs.  Then I could write the following:

    (defun some-complicated-command ()
      (interactive)
      (async-start/cc (lambda ()
                          ... do hard processing in a sub-emacs ...)

                        ;; Instead of being called with just the return value, 
the
                        ;; finish function is now also called with the result of
                        ;; (call/cc) after invoking the sub-Emacs

                        (lambda (ret cont)
                          (funcall cont)))

      (message "This processing happens *after* the callback is called."))

The difference here is that right now, `async-start' returns to the *caller*
immediately, with finalization code in the callback.  If I had `call/cc',
`async-start/cc' would return to the *user* immediately.  The callback's only
job would be to call the continuation, which would resume execution of the
stack that has spawned the asynchronous process.

The issue this addresses is that right now, if you call `async-start' when
call stacks are deep (Gnus, Eshell, etc.), the code has to be made aware that
finalization has been moved to a callback function.  It essentially has to be
"short-circuited", to know that asynchronicity is involved.

With continuations, we can push the current runtime stack into a variable, pop
back to the Emacs event loop immediately, and then resume that runtime stack
once the asynchronous function has finished executing.

Stefan/Chong: how hard would this be to add?  I'm aware we'd have to move away
from reliance on the C stack; but since they were able to make Python
stackless, I wonder how hard it would be to make Emacs Lisp the same?

John