Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104835
To: PHP internals <internals@lists.php.net>
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>
Message-ID: <301552a9-6f01-3177-0e57-3d9aac54cc0c@gmail.com>
Date: Wed, 20 Mar 2019 22:44:16 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <752c83ab-0e6f-d8f5-ff15-e1f75b5d04b5@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] RFC Draft: Comprehensions
From: rowan.collins@gmail.com (Rowan Collins)

On 20/03/2019 20:39, Stanislav Malyshev wrote:
> Hi!
>
>> It's not that you can't make an array into a generator, but you can't make
>> an eagerly-evaluated expression into a lazily-evaluated one.
> Not sure what you mean here.


I mean that, given a syntax that lazily-evaluates something, you can 
"fast-forward" the result to make it eagerly-evaluated; given a syntax 
that eagerly-evaluates something, you cannot do the opposite. Therefore, 
a lazy-evaluating syntax is more powerful, in that it can do everything 
an eager-evaluating one can do *and more*.


> In this particular case, when you're working with an iterator over a
> large file, you probably want a generator. Which is very easy to write
> using a functional syntax, and the only thing comprehension syntax does
> is switching the parts around a bit and saving you writing a "function"
> keyword. I don't think it's a very common case though.


Isn't that true of *every* use of the syntax, though, that "all it does 
is switch the parts around a bit"? There's nothing that an array 
comprehension can do that can't be done any other way, it's just 
short-hand; making it return a generator just extends that short-hand to 
more use cases.


> Of course, when you need to filter iterators, then you need a different
> approach. I do not doubt that. I doubt that filtering iterators is the
> most common case in PHP to make the comprehension syntax only support it
> - I think the case of array transformation is much more common.


I am not saying that it is "the most common case", and I am not saying 
that it should be the only thing supported. I am saying that if we don't 
have dedicated syntax for each, one way to support *both* variants is to 
make the iterator version the base case, and then have a universal 
syntax that switches it to an array.

If we do have syntax for both variants, then clearly both cases are 
covered anyway - although I think a short-hand for iterator_to_array 
would still have merit elsewhere.


>> But if we only have one, it should be the iterator version, with a
>> short-hand for iterator_to_array as a separate language improvement.
> I think this would significantly reduce the usability of such construct
> - to the point that it's easier to use the existing syntax, thus making
> new syntax sugar useless. The whole point of syntax sugar is making
> common case easy, and doing what you are suggesting is to make a corner
> case (existing, but IMHO much less common) easy and make the user work
> to achieve the common case.


I think you're arguing against a straw man here. Yes, the cost of the 
extra syntax should be weighed against the benefit of the extra 
flexibility. And IF the extra syntax was so verbose that it would be 
easier to use the existing syntax, that cost would probably be too high. 
But that's not what I was suggesting at all; I was picturing a new 
operator, a few characters long, which could turn any iterator into an 
array.

Are you really saying that something like this:

$a = [ ... (foreach $x as $y if $y < 2 yield $y) ];

would be so verbose that you'd rather write this:

$a = (function() use ($x) { $a=[]; foreach ( $x as $y ) if ( $y < 2 ) 
$a[] = $y; return $a; })();

or with the shortest closure syntax I can think of, this:

$a = (() => { $a=[]; foreach ( $x as $y ) if ( $y < 2 ) $a[] = $y; 
return $a; })();


By all means let's try to weigh the cost and benefit, but let's not jump 
to the conclusion that the cost is nearly infinite and the benefit is 
nearly zero.


Regards,

-- 
Rowan Collins
[IMSoP]