From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: ELisp futures and continuations/coroutines Date: Fri, 20 May 2011 03:23:57 +0200 Message-ID: <87d3jew4eq.fsf@ambire.localdomain> 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> <87oc2ywwuy.fsf@ambire.localdomain> <87r57uyaeu.fsf@lifelogs.com> <87hb8qwsmo.fsf@ambire.localdomain> <87oc2yuu8u.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1305854725 17451 80.91.229.12 (20 May 2011 01:25:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 May 2011 01:25:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 20 03:25:19 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 1QNESs-00036z-Oc for ged-emacs-devel@m.gmane.org; Fri, 20 May 2011 03:25:18 +0200 Original-Received: from localhost ([::1]:55471 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNESr-0006B0-P2 for ged-emacs-devel@m.gmane.org; Thu, 19 May 2011 21:25:17 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNESo-0006Aj-CD for emacs-devel@gnu.org; Thu, 19 May 2011 21:25:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QNESn-0001KF-Hd for emacs-devel@gnu.org; Thu, 19 May 2011 21:25:14 -0400 Original-Received: from smtp204.alice.it ([82.57.200.100]:49905) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QNESn-0001K4-7y for emacs-devel@gnu.org; Thu, 19 May 2011 21:25:13 -0400 Original-Received: from ambire.localdomain (87.5.65.6) by smtp204.alice.it (8.5.124.08) id 4D7E0F6405DD5A5E; Fri, 20 May 2011 03:25:09 +0200 Original-Received: from ttn by ambire.localdomain with local (Exim 4.69) (envelope-from ) id 1QNERZ-0003Nw-J2; Fri, 20 May 2011 03:23:57 +0200 In-Reply-To: <87oc2yuu8u.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu, 19 May 2011 18:48:49 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 82.57.200.100 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:139538 Archived-At: () Ted Zlatanov () Thu, 19 May 2011 18:48:49 -0500 Why tie futures to fsm.el or deferred.el specifically? That seems like an implementation detail. Well, one important detail, whether you consider it implementation or design, is who kicks the evaluation (and when). In the case of fsm.el, this is done by either a timer or from process input. A "future type" w/o this detail well-defined is no better than a simple closure (IMHO) because it has no concept of time / timing. Since invocation must be well-defined, so must the reception and stashing of the returned value(s) be done in a coordinated way. I think the "hello world" (demonstrating minimal sufficiency) of such a system is countdown timer. I'd rather establish a futures API: - create a future - is it done? - get result - inspect thrown error, if any which is simple, obviously, but it's essential so all the implementations that use it speak the same language. The answer to "is it done" is "never", if it never is kicked, tickled, invoked, prodded, probed, or otherwise moved to action. I like the defstruct because it's simple Yes, it's much cleaner than fsm's plist munging, but (as i tried to express above), that is just the shape of the sail and not the motion of the boat. (defstruct future callback errorback status value) [...] Keep going! If the above looks OK I can finish the implementation (error handling in `future-call' and around the callback/errorback invocations). Then any library can use ":include future" to add its own details on top of the `future' defstruct. Minimalism is nice, but i suppose i like a more full-featured "future type", one that can self-terminate, for example. Conniving computers, grumble... (i'll have to dig up and post some old fsm toys -- get a dozen of them going at once and you'll see what i mean :-D). -- a sig, not big, i fig, you dig?