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: [Emacs-diffs] master f6b5db6: Add support for generators Date: Tue, 03 Mar 2015 14:35:17 -0500 Message-ID: References: <20150302234252.19883.48595@vcs.savannah.gnu.org> <54F5FB63.3070203@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1425411346 11827 80.91.229.3 (3 Mar 2015 19:35:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Mar 2015 19:35:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 03 20:35:37 2015 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 1YSsbQ-0006Xq-ML for ged-emacs-devel@m.gmane.org; Tue, 03 Mar 2015 20:35:36 +0100 Original-Received: from localhost ([::1]:40526 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSsbQ-00036H-6o for ged-emacs-devel@m.gmane.org; Tue, 03 Mar 2015 14:35:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSsbK-00036C-8U for emacs-devel@gnu.org; Tue, 03 Mar 2015 14:35:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSsbH-0003fd-0J for emacs-devel@gnu.org; Tue, 03 Mar 2015 14:35:30 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:38190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSsbG-0003fS-N5 for emacs-devel@gnu.org; Tue, 03 Mar 2015 14:35:26 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t23JZLxo031607; Tue, 3 Mar 2015 14:35:21 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 7DDD3AE187; Tue, 3 Mar 2015 14:35:17 -0500 (EST) In-Reply-To: <54F5FB63.3070203@dancol.org> (Daniel Colascione's message of "Tue, 03 Mar 2015 10:20:19 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5234=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5234> : inlines <2342> : streams <1399406> : uri <1870163> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:183620 Archived-At: >> Do we want to document it as a function? Maybe it would be better to >> document it as an "object" of unspecified implementation (i.e. calling >> it via funcall rather than via iter-next is unsupported). > The iterator is an opaque object; a generator (of which an iterator is > an instance) is always a function. How can I make that clear? As I mentioned a bit further, the explanation about the difference between an iterator and a generator clarifies this, but comes a bit late. > Ecks. I accidentally the whole chapter. [ Thanks, that was a good one. ] >> To get back to iter-close, this seems to be a tricky aspect of the >> implementation. Could you give me more details, such as an example >> problematic case where calling iter-close makes a difference? >> I guess this has to do with those finalizers, so if you could explain >> how/why these are used, I'd really appreciate it. > In conventional Emacs Lisp, we're able to use unwind-protect to clean up > resources. I'd like generator functions to be as similar to regular Lisp > code as possible, and without support for closing iterators, preferably > automatically after GC, we'll violate this user expectation. Sure, it's > probably possible to work around the absence in specific cases, but > having to very careful will lead to leaks. The Python people had to add > a very similar feature in PEP 342 for much the same reason. I'm inclined to believe you that it's needed, but I'd really like to see some good explanation for why, probably with a motivating example. Ideally in a comment somewhere. >>> + (let* ((state (cl-gensym (format "cps-state-%s-" kind)))) >> ^^^^^^^^^ >> Elisp prefers make-symbol. > cl-gensym makes it possible to actually read the code the macro > produces. A wrapper that conditionally calls make-symbol should suffice. A wrapper is not worth the trouble. As for making `make-symbol' code readable, I use (setq print-gensym t) and/or (setq print-circle t). > Yes, we probably should --- but if we do that, we should impose some > kind of sane time limit on unwind-protect unwindforms in order to avoid > freezing Emacs. That is, we should be able to recover from > (unwind-protect nil (while t)) without having to attach a debugger or > send a signal. We should be able to recover from an inf-loop inside inhibit-quit in any case, yes. Normally C-g C-g C-g does it, but it kind of defeats the purpose in this case since users my lean on C-g without realizing that it has a different meaning. >> `(iter--blabla ,value (lambda (x) (iter-yield x))) > What do you mean? Move the unwind-protect and the loop into a separate higher-order function. > Fixed in a subsequent commit. Manually, though: maybe > macroexp-parse-body is the right thing. Yes, it's the new thing recently introduced, so that it handle "all" the special declaration-like thingies (docstrings, declare, cl-declare, you name it). Stefan