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:06:36 -0800 Message-ID: <54F6225C.3010804@dancol.org> References: <20150302234252.19883.48595@vcs.savannah.gnu.org> <54F5FB63.3070203@dancol.org> <54F621A9.90508@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N2UujeMaOG0l5KvXjTHuAUwx0Tb32lX0H" X-Trace: ger.gmane.org 1425416822 8691 80.91.229.3 (3 Mar 2015 21:07:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Mar 2015 21:07:02 +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:07:01 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 1YSu1h-0007Db-0u for ged-emacs-devel@m.gmane.org; Tue, 03 Mar 2015 22:06:49 +0100 Original-Received: from localhost ([::1]:40884 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSu1g-0006gW-E3 for ged-emacs-devel@m.gmane.org; Tue, 03 Mar 2015 16:06:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSu1c-0006dk-RD for emacs-devel@gnu.org; Tue, 03 Mar 2015 16:06:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSu1b-00085l-FS for emacs-devel@gnu.org; Tue, 03 Mar 2015 16:06:44 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:33325) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSu1b-00085g-57 for emacs-devel@gnu.org; Tue, 03 Mar 2015 16:06:43 -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=CKIQHdVg5SffeObWuWuVLTnOZLMbVIweqflhsoQMOGY=; b=hEgjsR2jTSPpltKibwTvWNiE7xnV6TOCyKNopqd06uhcWb6V3azdtzRr+AjG7yz9GazRwqRwDGb4pe7J+ENvAu8glcf6XyG/u1qu7thBS297ESrTyE0+/jSSSIrYIy6O94DpPTSaXsoG3iHZ1JpFZv7MY1T/e8M/7Agbeu2sGyoqU9s+3YEGen1D8d0IUw1W4cjWihmfPmS5U8BJxn5KdtvV6J569XnsZeicBBLCkLtYX2y2Dfq7KYRo2I5EC2zT6znRgnteht/rOZamTuBRoewKfPkRceus1x6uiVK/eLFLvCDutZj9U1yt2u6pmj7cTCiI2oko8k80tE1a7TjW9A==; 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 1YSu1a-000850-Ky; Tue, 03 Mar 2015 13:06:42 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 In-Reply-To: <54F621A9.90508@dancol.org> 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:183625 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N2UujeMaOG0l5KvXjTHuAUwx0Tb32lX0H Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 03/03/2015 01:03 PM, Daniel Colascione wrote: > On 03/03/2015 11:35 AM, Stefan Monnier wrote: >>>> Do we want to document it as a function? Maybe it would be better t= o >>>> document it as an "object" of unspecified implementation (i.e. calli= ng >>>> it via funcall rather than via iter-next is unsupported). >> >>> The iterator is an opaque object; a generator (of which an iterator i= s >>> 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. >=20 > Right. I'm not sure that level of detail is appropriate for the chapter= > introduction though. >=20 >>>> 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 explai= n >>>> 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 L= isp >>> code as possible, and without support for closing iterators, preferab= ly >>> 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 a= dd >>> 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 s= ee >> some good explanation for why, probably with a motivating example. >> Ideally in a comment somewhere. >=20 > 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 >=20 > (let ((line (iter-yield-from (easy-filter-read-line-async mumble))) > ;; Emacs runs while we're reading the line! > (do-something line)) >=20 > 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 wan= t > 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? Delet= e > a file? >=20 >>>>> + (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 suffi= ce. >> >> A wrapper is not worth the trouble. >=20 > I added one already. Mind leaving it there? >=20 >> 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 avo= id >>> 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 a= ny >> 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 func= tion. >=20 > 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. >=20 >>> 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" t= he >> special declaration-like thingies (docstrings, declare, cl-declare, yo= u >> name it). >=20 > Neat. Fixed. It's a shame we can't use it in `defmacro'. It's buggy for empty functions: ELISP> (macroexp-parse-body '("foo" (declare indent 5))) (("foo") (declare indent 5)) ELISP> (macroexp-parse-body '("foo" (declare indent 5) nil)) (("foo" (declare indent 5)) nil) --N2UujeMaOG0l5KvXjTHuAUwx0Tb32lX0H 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 iQIcBAEBCAAGBQJU9iJcAAoJEN4WImmbpWBlgDcP/i0ArG6/GOXQ1vnxbbbk7lB5 fkH7fEOWqaa4rbiwIIzxqYYCAIk1Eh6KGEafJw5xjxNSIvxj7GPIaPWhmjqYhje7 cqAbeNsFg9thvLMqeSbpX7AmJW5iey5D1OGZDhiwvdOlN80odSrUwM0GOfh7I638 wGHBCthaGYf25S7wF4+bKWtB9tVWWPxWs5fP060zhkB5ZhY5d7Izb1xK+M5v+pDF lsC/XqdsGMiHCFfNKwRW4MnffY522mbj4MtZMbcTJ1crci+sB3mlaS0Ywz9rVm3w ObRYtbhuX4EcSq+u5PRIUGA8mxKySZqN8k1KelQWayckX8FRg9fn56RK/3M0BEYH 2lOjTFh9yhFXR2QK15l899A6mawx01JyuzqZWuDN/TC8HcKjlDEh22zIrPz8T1jU /kn8AB6TDOABI0uRqZr+ODDxrC6XGxKF04YCz+BXqNXmem4iJSqmcwfJEeJrwnEj SPaP/HIAzkVi09qOrIUL2hR7WcPMHdHNaapJfMjr9dAJ8hnfoRJia+0FcD9+CdDj enOmlUsuN70O26UIhjnD8AdwaWfQeqTyK+1fZWz4kIuPLpJjuy+BXt/Nz41AyMIJ zkQ0Qd+Z11qeWvvusqMwOMFiB/5mGJxjAcvqg0Z5+fjWd+Sjaimc+4/eBOKziV/6 H74r3O1VZshZauro2DLC =aHCA -----END PGP SIGNATURE----- --N2UujeMaOG0l5KvXjTHuAUwx0Tb32lX0H--