[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ELisp futures and continuations/coroutines

From: Ted Zlatanov
Subject: Re: ELisp futures and continuations/coroutines
Date: Thu, 19 May 2011 17:51:20 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

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   : 
SM> concurrent.el : 

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 

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

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]