emacs-devel
[Top][All Lists]
Advanced

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

Re: ELisp futures and continuations/coroutines (was: more url-utils?)


From: SAKURAI Masashi
Subject: Re: ELisp futures and continuations/coroutines (was: more url-utils?)
Date: Fri, 20 May 2011 02:03:54 +0900
User-agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/23.2 Mule/6.0 (HANACHIRUSATO)

Hi, Ted

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

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

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

The chain of asynchronous callbacks likes the continuation.  Indeed,
concurrent.el that is build on deferred.el, has the pseud-thread, the generator 
and
the dataflow variable which may be similar to a "future" type.

A sample code of concurrent.el
https://github.com/kiwanami/emacs-deferred/blob/master/concurrent-sample.el

Here is a demo for the networking and UI thread. (Sorry for machine 
translation...)
http://translate.google.co.jp/translate?js=n&prev=_t&hl=ja&ie=UTF-8&layout=2&eotf=1&sl=ja&tl=en&u=http://d.hatena.ne.jp/kiwanami/20110413/1302709536

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

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

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


--
SAKURAI, Masashi (family, given)


At Thu, 19 May 2011 08:46:21 -0500,
Ted Zlatanov wrote:
> 
> On Wed, 18 May 2011 19:05:57 -0300 Stefan Monnier <address@hidden> wrote: 
> 
> SM> That's a good idea.  Kind of like a future.
> 
> Speaking of futures, can we have a general facility for those?
> 
> 1) a real "future" type
> 
> 2) a way to construct it and check if the value is available
> 
> 3) process sentinel tie-in
> 
> I'm sure much of this facility is either possible or already available
> in ELisp, I just don't know the pieces and I think it would be very
> convenient to provide a "future" type.  WDYT?
> 
> Similarly it would be very nice to provide continuations and coroutines
> if those are not already possible.  They don't need a top-level type
> though, a lexical closure is sufficient I think.  Please tell me how I'm
> wrong :)
> 
> Ted
> 
> 



reply via email to

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