Re: RFC Draft: Comprehensions

Den 2019-03-11 kl. 13:16, skrev Nikita Popov:

On Sun, Mar 10, 2019 at 10:45 PM Larry Garfield <larry@garfieldtech.com> 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 <https://wiki.php.net/rfc/comprehensions> 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