From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: RFC: Generators v2 Date: Sun, 25 Aug 2013 22:56:24 +0900 Message-ID: <87fvtxeuwn.fsf@uwakimon.sk.tsukuba.ac.jp> References: <52198EF7.50900@dancol.org> <87vc2uyy1o.fsf@ferrier.me.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1377439010 10691 80.91.229.3 (25 Aug 2013 13:56:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Aug 2013 13:56:50 +0000 (UTC) Cc: Emacs development discussions To: Nic Ferrier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 25 15:56:52 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VDaoG-0006Te-FZ for ged-emacs-devel@m.gmane.org; Sun, 25 Aug 2013 15:56:52 +0200 Original-Received: from localhost ([::1]:46201 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDaoG-0001Us-4f for ged-emacs-devel@m.gmane.org; Sun, 25 Aug 2013 09:56:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDao5-0001Nx-Ed for emacs-devel@gnu.org; Sun, 25 Aug 2013 09:56:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDanx-0003Vd-W6 for emacs-devel@gnu.org; Sun, 25 Aug 2013 09:56:41 -0400 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:60635) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDanx-0003U4-ET for emacs-devel@gnu.org; Sun, 25 Aug 2013 09:56:33 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 3C01A970A04; Sun, 25 Aug 2013 22:56:25 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id F35F11A3D92; Sun, 25 Aug 2013 22:56:24 +0900 (JST) In-Reply-To: <87vc2uyy1o.fsf@ferrier.me.uk> X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:163012 Archived-At: Nic Ferrier writes: > I'm personally uncomfortable about claiming `next'. At least use a > better name, like `gen-next'? Another possible name is `pop', I think. `pop' being a macro anyway it should be able to handle Yet Another Type of argument. `pop', because when applied to arguments, a generator returns an iterator whose API is like a list restricted to being consumed by iteration. I like `next', though. `next' is used in Python, at least, and it seems like the natural name to use. `gen-next'? No, thank you. > Perhaps it would be possible to avoid grabbing next by making it an > argument to the object returned by yield: > > (defgenerator y (x) [...]) > > (let ((g (y 10))) > (funcall g :next) > (funcall g :next) > (funcall g :next)) => 7 I think the package is misusing the name "generator". If `g' is a function (which it seems it indeed is in this package), it's already possible to create closures in various ways, so that a function carries its state with it. So this is just syntactic sugar for closures. Indeed this syntactic sugar is *very* useful for coroutines and the like, but it's not really useful for generators. The point of a generator is that it returns an iterable, ie, an object which looks like a sequence in an iteration context. In particular, code that can iterator over the value of a generator should be able to use an ordinary list in the same place, *without* knowing which it's going to get in advance. I don't see how you make that work generically if generators return functions. You have to alter *every* iteration construct to recognize generators. And then what happens if you hand it an ordinary function? Is it possible to distinguish between a function created with defun, and the value of a generator created with defgenerator? I don't see how (without introspecting the code for yields). > The only thing nicer than that would be to have generators be real > lisp-1 functions: Too bad that Emacs Lisp is a Lisp-2, I guess. You actually could do that Lisp-2-fully in a specific syntactic context, though: ; pass the syntactic sugar, plz ; oh, yeah, the gencinnamon, too! then you can omit the fmakunbound (prog2 (define-function 'g (y (10))) (g) (fmakunbound 'g)) => 9 It should be easy enough to do that with a macro, though I don't see how to make it very general. Steve