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: RFC: Generators v2 Date: Sun, 25 Aug 2013 13:00:11 -0700 Message-ID: <521A624B.8050805@dancol.org> References: <52198EF7.50900@dancol.org> <87vc2uyy1o.fsf@ferrier.me.uk> <87fvtxeuwn.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5BaBnDLxWr63XtIHkBdgfAtl5t3vUoXDD" X-Trace: ger.gmane.org 1377460900 28323 80.91.229.3 (25 Aug 2013 20:01:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 25 Aug 2013 20:01:40 +0000 (UTC) Cc: Nic Ferrier , Emacs development discussions To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 25 22:01:42 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 1VDgVJ-0008HU-J7 for ged-emacs-devel@m.gmane.org; Sun, 25 Aug 2013 22:01:41 +0200 Original-Received: from localhost ([::1]:47473 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDgVJ-0007Z2-81 for ged-emacs-devel@m.gmane.org; Sun, 25 Aug 2013 16:01:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54146) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDgV7-0007Xw-CE for emacs-devel@gnu.org; Sun, 25 Aug 2013 16:01:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VDgUy-0000TL-VJ for emacs-devel@gnu.org; Sun, 25 Aug 2013 16:01:29 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:51322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VDgUy-0000TF-Lx for emacs-devel@gnu.org; Sun, 25 Aug 2013 16:01:20 -0400 Original-Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[192.168.1.52]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1VDgUu-0004gz-Lm; Sun, 25 Aug 2013 13:01:16 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 In-Reply-To: <87fvtxeuwn.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.5.2 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:163022 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5BaBnDLxWr63XtIHkBdgfAtl5t3vUoXDD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8/25/13 6:56 AM, Stephen J. Turnbull wrote: > Nic Ferrier writes: >=20 > > I'm personally uncomfortable about claiming `next'. At least use a > > better name, like `gen-next'? >=20 > 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. I also like the idea of using pop, but you'd have to determine at runtime whether you were popping from an iterator or a list, and I'm not really comfortable adding that overhead. I'd prefer 'next' over 'gen-next' or other alternatives: we're talking about a generic iteration protocol. The chief problem with using generic names is that they're often tied to concepts that are too specific. In this case, though, we're giving a generic concept a generic name, and I think that's fine. >=20 > > Perhaps it would be possible to avoid grabbing next by making it an > > argument to the object returned by yield: > >=20 > > (defgenerator y (x) [...]) > > > > (let ((g (y 10))) > > (funcall g :next) > > (funcall g :next) > > (funcall g :next)) =3D> 7 >=20 > 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. The package uses a tree walker to rewrite swaths of code into continuation passing style. If you think that's sugar, I'd love to see what you consider meat. :-) > 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. =20 Ideally, yes, and in something like Clojure, we'd be able to do that with existing languages primitives --- but here, our options for runtime polymorphism are limited. Providing ways to conveniently iterate over iterators (and making these constructs also handle today's sequences) would be sufficient. I don't see how you make that work generically if > generators return functions. You have to alter *every* iteration > construct to recognize generators. There are only a few. What's the alternative: a special kind of cons cell that lazily generates its car and cdr? I suppose that could work, but I'd be worry about unintended side effects. > 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). >=20 I suppose it's possible to wrap the returned function in some easily-distinguishable wrapper, but why would you want to? --5BaBnDLxWr63XtIHkBdgfAtl5t3vUoXDD 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.4.14 (Darwin) iQIcBAEBAgAGBQJSGmJPAAoJEMAaIROpHW7IoIEQAMLcm0cYFVo+7yJ+pGitu6Fj YfWGtbIW2PkNbyFPd2fopf/0IoNN2PMXx9dfmR0U/LKnE5bazY8V7tZLWCZg31hU tjCgv87CCxJX4jYeCwkk28uMA3VmAMS9fANiAm+lgJIxih1bAGFuYTzINQ23RGwt E0efjWNF/LFyAe6LXo9iJyU12OX3BW80uUYZ2UNtuWPyewE9u0I7YIAPWEcxOtJk gtifDdkDn/2gHnFI497sisFfzdmYjKj8FRkfYbwkcNE5EoC6m8b+MqkfIBz6ruQB 0Yxq4rb9oWjUIasKPEtGad68F5+CS2IbsQHmd+/PdO7UW2wURhu2V4W8q76yOgR2 c9/nvH0p9Sjb49esgO6tQefdJ4lOVsYyQbivNiOAutJEXmSbR99FXFeWzaK2xpN+ /k4M8G8tlmCF57r/v7NXYBgyo8xvtsSXH5wdKpDDCuyU1hGe1/vdMiiFkyKfSJ0s Ek62XXn5SOazJ+qMJgXbhY/6F96ha5FPgxUYGkNlMZ5NNAX064pPkaSs8MakE1f+ AkFrjsP30C+NJqjHtJvNoEqk/mVkJ0h9qKbit9mw3m54254lhACct90rb/ySooBb DEaEeE1nvy/6S5e8MvyocSyCMbKdwMzOD8irvl4m9g6KiVi/QLTaXfsPf8XpSS7K I+lDpo4rACUIWRPwwsV6 =4VBm -----END PGP SIGNATURE----- --5BaBnDLxWr63XtIHkBdgfAtl5t3vUoXDD--