From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: ELisp futures and continuations/coroutines Date: Fri, 03 Jun 2011 11:06:22 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87ipsmgarl.fsf@lifelogs.com> References: <87boz0eov8.fsf@lifelogs.com> <87mxikrulm.fsf@lifelogs.com> <871uzw5asv.fsf@lifelogs.com> <878vu2ztua.fsf_-_@lifelogs.com> <87oc2ywwuy.fsf@ambire.localdomain> <87r57uyaeu.fsf@lifelogs.com> <87hb8qwsmo.fsf@ambire.localdomain> <87oc2yuu8u.fsf@lifelogs.com> <87d3jew4eq.fsf@ambire.localdomain> <8739k9s84c.fsf@lifelogs.com> <87tycmzxg3.fsf@ambire.localdomain> <87k4dh3363.fsf@lifelogs.com> <874o4l311n.fsf@lifelogs.com> <20110523154258.55B6813C480@vps1.kiwanami.net> <871uznbki1.fsf@lifelogs.com> <20110603135948.C290D13C538@vps1.kiwanami.net> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1307119061 21896 80.91.229.12 (3 Jun 2011 16:37:41 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 3 Jun 2011 16:37:41 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 03 18:37:32 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 1QSXNI-0008WV-SU for ged-emacs-devel@m.gmane.org; Fri, 03 Jun 2011 18:37:29 +0200 Original-Received: from localhost ([::1]:59792 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSXNH-0004ol-TK for ged-emacs-devel@m.gmane.org; Fri, 03 Jun 2011 12:37:28 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSWtW-0005bm-D6 for emacs-devel@gnu.org; Fri, 03 Jun 2011 12:06:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSWtS-0008G0-Qw for emacs-devel@gnu.org; Fri, 03 Jun 2011 12:06:42 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:44739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSWtS-0008Fj-DJ for emacs-devel@gnu.org; Fri, 03 Jun 2011 12:06:38 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QSWtQ-0008PN-Cw for emacs-devel@gnu.org; Fri, 03 Jun 2011 18:06:36 +0200 Original-Received: from 38.98.147.130 ([38.98.147.130]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Jun 2011 18:06:36 +0200 Original-Received: from tzz by 38.98.147.130 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 Jun 2011 18:06:36 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 60 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.130 X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:j/ikxIXtMr9ouT7P2oICv8PJm+c= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:140135 Archived-At: On Fri, 03 Jun 2011 22:59:48 +0900 SAKURAI Masashi wrote: SM> At Tue, 24 May 2011 21:07:50 -0500, SM> Ted Zlatanov wrote: >> : >> Also please see the discussion in this thread about url-future.el. If >> you can consider augmenting that defstruct instead of using the one in >> deferred.el, it would be nice so we're all speaking the same data >> language. I asked the same of Thien-Thi Nguyen for fsm.el. But it's >> not a requirement for inclusion in the GNU ELPA and you don't have to do >> it. SM> About the "future" type for the just url-fetch function, I think it is SM> good enough to transfer values asynchronously to the waiting function. SM> However, I think it is somewhat primitive to construct general SM> asynchronous programs. The future type is intentionally a simple pure data type. It can be extended with `defstruct'. Is the data type missing something you need? Can you convert concurrent.el to derive its data type from the url-future struct and use the url-future-* functions, or is there something blocking that conversion? When I looked at concurrent.el, the data type it uses was very similar to the url-future defstruct. SM> While I'm not a researcher for the concurrent programing, SM> investigating such other async libraries, I found that asynchronous SM> programing needs at least following two functions: SM> 1) sequential connecting SM> 2) waiting for async tasks done (all of them or the earliest one). SM> One can define many other aspects of async programing. SM> Ex. composition of tasks, error handling, canceling, propagating SM> values, adding tasks after executed, restarting tasks, notifying SM> progress and so on[3]. Sure, but all of these are functional requirements. url-future.el only addressed the "futures" protocol, so we can speak a common data language. It doesn't provide any actual async support. That's the job for concurrent.el and deferred.el among others. SM> Though concurrent.el has some patterns those were implemented for my SM> applications, of course, it doesn't cover all patterns. According to SM> other languages and some books, STM, Agent, Actor, Reentrant Lock and SM> Read-Write Lock are argued as concurrent programing. I'm not sure how much of that is needed in Emacs. Perhaps these needs will become more apparent when the concurrency branch is merged, though I have no idea when that will hapen. SM> Last, if my experience of development of deferred.el and concurrent.el SM> would help the Emacs's advance, I would be happy. I don't mind if SM> the libraries will be added to GNU ELPA or Emacs, even the maintainers SM> write a subset code from scratch. You need to sign the assignment papers. One of the Emacs maintainers can help you with that. I think assign@gnu.org is the general contact point for any copyright assignment questions. Ted