From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: SAKURAI Masashi Newsgroups: gmane.emacs.devel Subject: Re: ELisp futures and continuations/coroutines Date: Sat, 21 May 2011 00:49:09 +0900 Message-ID: <20110520154909.A887513C4B5@vps1.kiwanami.net> References: <87fwogaxzb.fsf@stupidchicken.com> <87mxilezg8.fsf@lifelogs.com> <87boz0eov8.fsf@lifelogs.com> <87mxikrulm.fsf@lifelogs.com> <871uzw5asv.fsf@lifelogs.com> <878vu2ztua.fsf_-_@lifelogs.com> <20110519170354.3E15F13C514@vps1.kiwanami.net> <87wrhmuwwn.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: dough.gmane.org 1305906566 9931 80.91.229.12 (20 May 2011 15:49:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 May 2011 15:49:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: tzz@lifelogs.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 20 17:49:22 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QNRx0-00007y-BR for ged-emacs-devel@m.gmane.org; Fri, 20 May 2011 17:49:18 +0200 Original-Received: from localhost ([::1]:38908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNRwz-0004W4-Tk for ged-emacs-devel@m.gmane.org; Fri, 20 May 2011 11:49:17 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:44384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNRww-0004UV-I9 for emacs-devel@gnu.org; Fri, 20 May 2011 11:49:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNRwv-00018B-43 for emacs-devel@gnu.org; Fri, 20 May 2011 11:49:14 -0400 Original-Received: from vps1.kiwanami.net ([182.48.41.71]:57083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNRwu-000178-Os for emacs-devel@gnu.org; Fri, 20 May 2011 11:49:13 -0400 Original-Received: from liza2.kiwanami.net (localhost [127.0.0.1]) by vps1.kiwanami.net (Postfix) with ESMTP id A887513C4B5; Sat, 21 May 2011 00:49:09 +0900 (JST) In-Reply-To: <87wrhmuwwn.fsf@lifelogs.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/23.2 Mule/6.0 (HANACHIRUSATO) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 182.48.41.71 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139554 Archived-At: At Thu, 19 May 2011 17:51:20 -0500, Ted Zlatanov wrote: > : > 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. I employed the anaphoric macros to simulate the method chains in conventional OOP languages or the "do" syntax in Haskell. I feel that it is not so good too. I would learn the better ideas. * JavaScript (JSDeferred): http.get("http://example.com/"). next(function(result) { alert(result); }); * Haskell: main = do x <- getContents putStr x * elisp (deferred.el): (deferred:$ (deferred:url-retrieve "http://www.gnu.org") (deferred:nextc it (lambda (buf) (insert (with-current-buffer buf (buffer-string))) (kill-buffer buf)))) > 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. Yes. The library deferred.el focuses on just supporting asynchronous callback programing. So, it is different from the "future" type that you mentions in some aspects. Although on the higher abstract layer, those ideas and implementations may be identical, the users like practical ones. It seems that many JavaScript developers like the word "deferred", and that the Java, C++ and other functional languages developers like "future". > 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. I see. I think the developers who are familiar to JavaScript's deferred like deferred.el. > 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. Thank you. I'm encouraged. -- SAKURAI, Masashi (family, given)