Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104846
MIME-Version: 1.0
References: <a70baca7-f0af-49de-9cf9-5421e42e0a0c@www.fastmail.com>
 <CAF+90c9nrLQGfxoJWi72xatxz21qvqc5jyRnnHpcgivumhSXeg@mail.gmail.com>
 <85417a73-a391-c9ad-49aa-5b88c65b0900@gmail.com> <5c8ea43d.1c69fb81.e50f1.7d18SMTPIN_ADDED_MISSING@mx.google.com>
 <d21ae93f-d275-f526-7e2a-abe9a3a14397@gmail.com> <CAMuFt-5WQm13WkkKWO3MnzdqQ4ruKM8=8panK10SvCfyeVuDXg@mail.gmail.com>
 <0d34b3b1-866e-4bab-9a8f-3c70f1fc9721@www.fastmail.com> <c526a0b3-012c-a582-8933-619629f44c7e@gmail.com>
 <CALKiJKpXOfrVPRueU-BLBXHwNimBbsJZebY=u42gFLa3mdV7Lg@mail.gmail.com>
 <752c83ab-0e6f-d8f5-ff15-e1f75b5d04b5@gmail.com> <301552a9-6f01-3177-0e57-3d9aac54cc0c@gmail.com>
 <CAMuFt-5kWXUYiRU2b35EHDbSPbgkYjcUWFB8wr64fZM1VyCXJw@mail.gmail.com>
 <7A288F12-1227-4E78-8F9A-0959432F02D8@gmail.com> <CAMuFt-7JEKg2TaD9067DA9qrOxg91aJNZbOLK9fYj94XY=nTrg@mail.gmail.com>
In-Reply-To: <CAMuFt-7JEKg2TaD9067DA9qrOxg91aJNZbOLK9fYj94XY=nTrg@mail.gmail.com>
Date: Thu, 21 Mar 2019 12:29:13 +0000
Message-ID: <CALKiJKqKCML78TCWeB-Tu5hAYPq-4_qT2=tLfyj+D3NiBn9bDw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000821522058499e3d5"
Subject: Re: [PHP-DEV] RFC Draft: Comprehensions
From: rowan.collins@gmail.com (Rowan Collins)

--000000000000821522058499e3d5
Content-Type: text/plain; charset="UTF-8"

On Thu, 21 Mar 2019 at 11:00, Robert Hickman <robehickman@gmail.com> wrote:

> I was only making a point for where a non-generator version of
> comprehensions could be useful, under the premise "Therefore, a
> lazy-evaluating syntax is more powerful, in that it can do everything
> an eager-evaluating one can do *and more*.". This implies that it
> dosn't have any downsides, whereas performance may be a downside.
>


Ah, OK, I see where you're coming from. I'm no expert, but I'm not sure how
much difference it would actually make.

Whether the comprehension is eagerly evaluated internally, or by a call to
iterator_to_array, the input will always need to looped over exactly once,
with each element being tested against the condition and run through the
output mapping.

A manual eager implementation (with no output mapping, for simplicity)
would look like this:

foreach ( $array as $element ) {
    if ( someCondition ) $newArray[] = $element;
}

Which is basically equivalent to this:

while ( $element = $arrayIterator->next() ) {
    if ( someCondition ) $newArray[] = $element;
}

A lazy implementation just moves the if check into the iterator; it might
look like this:

while ( $element = $filteredArrayIterator->next() ) {
    if ( someCondition ) $newArray[] = $element;
}

But  $filteredArrayIterator->next() is actually $arrayIterator->next() with
a built-in if check, so you could also picture it as doing this:

while ( $element = $arrayIterator->nextIf ( someCondition ) ) {
    $newArray[] = $element;
}

So the underlying operations are the same, they just happen in different
orders.


The only real difference I can see is that under a very specific set of
circumstances, it could be compiled into a tight loop on the CPU. It would
require a JIT to check all of the following held, though:

- The input is a plain array, not any other iterable
- The condition can be inlined (e.g. not a function call like "if (
checkSomething($x) )")
- The output mapping can be inlined (e.g. not a function call like "yield
doSomething($x)")

Returning a generator by default just requires an extra check in that list:

- The expression is contained within iterator_to_array (or whatever syntax
shortcut we come up with for that).


I might be wrong, though, in which case this would indeed be an argument in
favour of having a dedicated array-returning syntax, either alongside or
instead of a generator-returning one.


Regards,
-- 
Rowan Collins
[IMSoP]

--000000000000821522058499e3d5--