Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104677 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 89309 invoked from network); 12 Mar 2019 18:34:07 -0000 Received: from unknown (HELO v-smtpout1.han.skanova.net) (81.236.60.154) by pb1.pair.com with SMTP; 12 Mar 2019 18:34:07 -0000 Received: from [192.168.7.8] ([213.64.245.126]) by cmsmtp with ESMTPA id 3jG4hivY9PDfH3jG4hUgHO; Tue, 12 Mar 2019 16:24:01 +0100 To: Nikita Popov , Larry Garfield Cc: PHP internals References: Message-ID: Date: Tue, 12 Mar 2019 16:24:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-CMAE-Envelope: MS4wfNNPQ7s2LlcsILRtMNp7hdYKv21aoccIjd/EXgGRBSvJaA0mQ+sk3psMu0Tl4YlPoovf9/Anfoto10DM7FGB+Xi8LRHGJy6IR0AnsYJMGCr/CLlJAiQe IEzAKX0VY03U0BGms1HtQwf3CzOVlRoPg6CxrS6DvkjI9+y7FpkYbSma0zLUJuc5WOCtRf1rQntGqB5NZRU8ydOyBfJDSKIkgfV48wrkwyq5X3KKTN6K0bHN s1gOFbg2YiX7j84EPV2s9A== Subject: Re: [PHP-DEV] RFC Draft: Comprehensions From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=) Den 2019-03-11 kl. 13:16, skrev Nikita Popov: > On Sun, Mar 10, 2019 at 10:45 PM Larry Garfield > wrote: > >> Hello, peoples. I know it's been discussed once or twice before on the >> list, many years ago, but not recently. I therefore feel OK putting forth >> the following draft proposal for Comprehensions, aka "compact generators", >> in PHP: >> >> https://wiki.php.net/rfc/cohttps://externals.io/message/61021mprehensions >> >> >> Sara Golemon has written a preliminary patch that is partially complete >> (see the RFC link for details, it's impressively simple), but unfortunately >> doesn't have the bandwidth to complete it at this time. I am therefore >> looking for collaborators with more knowledge of internals than I (which is >> almost everyone) to help finish it up. >> >> The syntax proposed is also subject to revision if a terser but still >> lexer-friendly alternative can be proposed. >> >> At the moment I'm not calling this Proposed yet, as I don't feel >> comfortable doing so until someone else is on board to finish coding it. >> That said, if someone wants to weigh in on the concept for now (hopefully >> supportively) that's also fine. >> >> Anyone excited enough to help finish the job? >> >> (This is my first RFC collaboration, so if you're going to smack me for >> goofing something please be gentle about it.) >> > I've brought up a similar proposal a few years ago, probably around the > time generators were first introduced: https://externals.io/message/61021 > > I think my main point of feedback would be to stick closer to existing PHP > syntax, even if it costs us some brevity. I would prefer > > $gen = [foreach ($list as $x) if ($x % 2) yield $x * 2]; > > over > > $gen = [for $list as $x if $x % 2 yield $x * 2]; > > The latter is nice in languages that generally use "for" for this purpose > and generally allow omitting parentheses, but I don't think it's good to > introduce this kind of syntax inconsistency in one place. > > Similarly, I found the ability to omit the "yield" expression somewhat > confusing. Especially once you get to nesting > > $gen = [for $a as $b for $b as $c]; > > the behavior becomes non-obvious. Also wondering how this part interacts > with keys, do you decide whether or not to yield the keys based on whether > they are part of the for expression? > > $gen = [for $list as $v]; // drops keys > $gen = [for $list as $k => $v]; // keeps keys > > Finally, Python makes a distinction between list comprehensions using [] > and generator expressions using (). This proposal effectively corresponds > to generator expressions, but uses the [] syntax. I'm wondering if that > will cause confusion. > > Regards, > Nikita As a userland developer I found the example parsing large log files from the proposal a few years back a good use case for this feature. Besides that, I recall that for arrow functions a few different syntax proposals were on the table. Wonder which one of those plays best with this proposal? Maybe that should be taken into consideration when looking at this RFC. r//Björn L