From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: RFC: Generators v2 Date: Mon, 26 Aug 2013 12:05:52 -0400 Message-ID: References: <52198EF7.50900@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1377533170 5587 80.91.229.3 (26 Aug 2013 16:06:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 Aug 2013 16:06:10 +0000 (UTC) Cc: Emacs development discussions To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 26 18:06:12 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 1VDzIv-0003yy-Cc for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2013 18:06:09 +0200 Original-Received: from localhost ([::1]:52085 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDzIu-0000Ko-V2 for ged-emacs-devel@m.gmane.org; Mon, 26 Aug 2013 12:06:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDzIm-0000Kj-7q for emacs-devel@gnu.org; Mon, 26 Aug 2013 12:06:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDzIg-0007tK-Dp for emacs-devel@gnu.org; Mon, 26 Aug 2013 12:06:00 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:5089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDzIg-0007tD-9V for emacs-devel@gnu.org; Mon, 26 Aug 2013 12:05:54 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+KK6/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBgzBHQSRCgOkeoFegxM X-IPAS-Result: Av4EABK/CFHO+KK6/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBgzBHQSRCgOkeoFegxM X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="24368042" Original-Received: from 206-248-162-186.dsl.teksavvy.com (HELO pastel.home) ([206.248.162.186]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 26 Aug 2013 12:05:46 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E150A63BAF; Mon, 26 Aug 2013 12:05:52 -0400 (EDT) In-Reply-To: <52198EF7.50900@dancol.org> (Daniel Colascione's message of "Sat, 24 Aug 2013 21:58:31 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:163034 Archived-At: > At https://github.com/dcolascione/elisp-generators, I've updated my > elisp generator support. Please take a look. I like generators, and your package looks interesting. I'd be very happy to put it in GNU ELPA at least. > integration, a few more testcases, and a lexical-binding assertion. The top-level (assert lexical-binding) checks that lexical-binding is true at run-time, whereas you only care about its value at macro-expansion time. > I'd eventually like to integrate this package into the Emacs core, As I said, I like the idea. But I'm wondering how well it works in practice. The code it generates seems to be extremely inefficient (not that I know an easy way to make it more efficient, mind you). > so I've laid claim to a few symbols in the global namespace, like > next. IIUC `yield' can only appear lexically within `defgenerator', so whether its namespace-cleanliness is not much of a problem. I see we already have `next' in Emacs's core, which we call `funcall'. I agree that `funcall' is not an intuitive name, but I'm not sure I like the idea of claiming `next' for it, right now. If/when generators move to the core, I might change my mind, of course. We could do away with the funcall altogether using an flet-like macro: (flet-like ((g (y 10))) (g) (g) (g)) => 7 > This package actually defines a generic iterator protocol, and > it'd be useful eventually to define iterator objects for things like > buffers and windows instead of relying on enumeration callbacks. Agreed, Stefan