From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master f6b5db6: Add support for generators Date: Tue, 03 Mar 2015 13:03:37 -0800 Message-ID: <54F621A9.90508@dancol.org> References: <20150302234252.19883.48595@vcs.savannah.gnu.org> <54F5FB63.3070203@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Xo4E50bXLBlfagpK8VujnjAlCHEq4EUHJ" X-Trace: ger.gmane.org 1425416646 5885 80.91.229.3 (3 Mar 2015 21:04:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Mar 2015 21:04:06 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 03 22:04:05 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 1YStyp-0005SR-S4 for ged-emacs-devel@m.gmane.org; Tue, 03 Mar 2015 22:03:52 +0100 Original-Received: from localhost ([::1]:40867 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YStyp-0003Vr-9O for ged-emacs-devel@m.gmane.org; Tue, 03 Mar 2015 16:03:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33967) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YStyk-0003TO-TS for emacs-devel@gnu.org; Tue, 03 Mar 2015 16:03:48 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YStyj-0006qo-Nx for emacs-devel@gnu.org; Tue, 03 Mar 2015 16:03:46 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:33322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YStyj-0006qj-A4 for emacs-devel@gnu.org; Tue, 03 Mar 2015 16:03:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4qg7/ll3OafCBfFIqivG9eSH9T8EACCPh/xW7xwR+64=; b=T98diTDenxC8GPZuQ7mXZyxMvWD89cGu0zeIAR9MBSea54uosBO7WSt87WM8Rted3W1dQeEMMbW9MOLXkmGPURSgUKMSAj3J07IZJ+v3Uha3o+jGJd+ZdKhg5OtIf/i/qZg+/CYdAdjanlNPNT+BXlMmGxTZuhdk34lxbAAcBKG84fIMGU79I8GbSxgunNUd3iaabnwDCD5vcLinjWn9zYN3AptLv/fKOQdWcyeva7FqiVHL3KW+JOzw4nwRBUrC73Zuj8UxJ5f8lRH49V8b3L1rdsWx12IpdQq03ueyeCcfQL9//4pHvo0t5OWX5pBrDH+2YvjmHDmpwP9K1/TyCg==; Original-Received: from [2620:10d:c083:1003:2ab2:bdff:fe1c:db58] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1YStyh-00084C-Iz; Tue, 03 Mar 2015 13:03:43 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:183623 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Xo4E50bXLBlfagpK8VujnjAlCHEq4EUHJ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/03/2015 11:35 AM, Stefan Monnier wrote: >>> 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. callin= g >>> it via funcall rather than via iter-next is unsupported). >=20 >> 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? >=20 > As I mentioned a bit further, the explanation about the difference > between an iterator and a generator clarifies this, but comes > a bit late. Right. I'm not sure that level of detail is appropriate for the chapter introduction though. >>> 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. >=20 >> 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 Li= sp >> code as possible, and without support for closing iterators, preferabl= y >> 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 ad= d >> a very similar feature in PEP 342 for much the same reason. >=20 > I'm inclined to believe you that it's needed, but I'd really like to se= e > some good explanation for why, probably with a motivating example. > Ideally in a comment somewhere. I don't have one yet, and that's mostly because the higher-level facilities I want to build on top of generators don't exist yet. In particularly, I'd like to build something that makes process filters easier to write, that would allow you to write something like (let ((line (iter-yield-from (easy-filter-read-line-async mumble))) ;; Emacs runs while we're reading the line! (do-something line)) I don't want to iter-close later: if we add it, we'll change the semantics of existing unwind-protect blocks. It feels better to do it right from the start. I can think a few possible resources we might want to clean up: what if we want to unload a module when it's no longer needed? Kill a hidden buffer? Remove overlays? Kill a subprocess? Delete a file? >>>> + (let* ((state (cl-gensym (format "cps-state-%s-" kind)))) >>> ^^^^^^^^^ >>> Elisp prefers make-symbol. >=20 >> cl-gensym makes it possible to actually read the code the macro >> produces. A wrapper that conditionally calls make-symbol should suffic= e. >=20 > A wrapper is not worth the trouble. I added one already. Mind leaving it there? > As for making `make-symbol' code readable, I use (setq print-gensym t) > and/or (setq print-circle t). >=20 >> 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 avoi= d >> 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. >=20 > We should be able to recover from an inf-loop inside inhibit-quit in an= y > 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. >=20 >>> `(iter--blabla ,value (lambda (x) (iter-yield x))) >> What do you mean? >=20 > Move the unwind-protect and the loop into a separate higher-order funct= ion. I'm not sure that would help. We need to keep the `iter-yield' in the body of the calling function in order to be correct. >> Fixed in a subsequent commit. Manually, though: maybe >> macroexp-parse-body is the right thing. >=20 > Yes, it's the new thing recently introduced, so that it handle "all" th= e > special declaration-like thingies (docstrings, declare, cl-declare, you= > name it). Neat. Fixed. It's a shame we can't use it in `defmacro'. --Xo4E50bXLBlfagpK8VujnjAlCHEq4EUHJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJU9iGpAAoJEN4WImmbpWBlqvYP/Aw4X4+dKL33wiG3tgPNl0IV LBJ2d2N+r4U0m2llX7TBz/xJzKQfcI8AsApep2QbNRPqqsLhF038wYE4ZcTaDuEm vWSmAfgCaw+agFpYQW+Ykx4D/8tklCFF/qpmhz3AmTJ5Vm42YSz/6eifq9NW9vY7 zIdVjHkACXEPBR6W9pg2V+Z6P6J+WELxHS2nfRb5WhV8zBYaMrwJdbJTXUnfn0UY 1UtP2ETGyqLOF8d0PKucoq+HGks24JIkp47ATu0qvHQ0FxhYLC96wqCg3cRaoTgV XNJKzqgQmT2aNyssLVaY88Tb337/K8MiDlPeGfFLBMcqfJpuilheikjedMab5zqP RV+OLkT0wCUOMOILM33nUddyVyHFvPeVRI/aQqVJL3GDLmud7JrScu0DSPde0nA1 NSfMt9EZeGlBliNYjZMf7D/hKBrG5YZ9mdSD1MLyrGqr2caD7jfUH1p4S093IoCR WD+2cm57yGo+EIWi2f2LfVOt7+UN5QWItfuZDceDUSRdQ2iwBThNeZMVHkedbKvd WTvWJruOwamPkgGunXJCn3VljOJG8335BKuYka2cYMF5qcZNWegqjIDkGqgrc/0v KQ+CB9vp+rwipJGIAWvkWAST5TmPldLCu75COXLJ0mPN72OhNnIC3SVKB4vphZfC pQ4SWFvsgQ4GB2pRsgLu =B/WW -----END PGP SIGNATURE----- --Xo4E50bXLBlfagpK8VujnjAlCHEq4EUHJ--