Re: ELisp futures and continuations/coroutines

[Ted Zlatanov]

On Fri, 20 May 2011 02:03:54 +0900 SAKURAI Masashi <address@hidden> wrote: 

SM> I have just made an asynchronous library, deferred.el and concurrent.el.

SM> deferred.el   : 
https://github.com/kiwanami/emacs-deferred/blob/master/README.markdown
SM> concurrent.el : 
https://github.com/kiwanami/emacs-deferred/blob/master/README-concurrent.markdown

SM> deferred.el is inspired by JSDeferred that comes from Mochikit.Async(JS) 
and Twisted(Python).

I looked at the code and it's pretty nice.  It needs some small cleanup
to be part of Emacs.

SM> I have written some applications built on deferred.el and I found it works 
well.

It's a good library, but maybe too complicated for general use.  I don't
know how the maintainers feel about anaphoric macros and chained
futures.  The resulting code, while neat, is IMO hard to understand if
you don't understand the underlying macros.

Also, the library does a lot more than futures, and I think it would be
nice to separate just the futures (the `deferred' defstruct).  But the
way they are implemented currently, the queue implementation is implicit
in the future definition itself.

SM> I think handling of asynchronous callbacks is getting important for
SM> the Emacs in the future. Because the Emacs interpreter is built on
SM> the single thread model (Node.js also employs the single thread
SM> model), the Emacs Lisp should have a way to write complicated
SM> asynchronous codes more easily.

I think with lexical closures Emacs is getting closer to true
concurrency, which is better than simulating it in a single-threaded
way.  I like your approach, it's just (like fsm.el) that it's a very
specific way of doing things that doesn't fit with the rest of ELisp
code, so I don't think it should be the *standard* way to do futures or
continuations.

This is just my opinion; the Emacs maintainers should say what they
think.

SM> I would like to include deferred.el in the Emacs package.

I'm in favor, it's a good library and more useful in the core than in
the GNU ELPA.

Ted