Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111734
User-Agent: Cyrus-JMAP/3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a
Mime-Version: 1.0
Message-ID: <b079c8e0-a2fe-47da-9d00-89f8b53c9a11@www.fastmail.com>
In-Reply-To: 
 <DM6PR07MB66183421EB52AD2928C6C365F9500@DM6PR07MB6618.namprd07.prod.outlook.com>
References: 
 <DM6PR07MB66188EBF51D1BED2560BC889F9530@DM6PR07MB6618.namprd07.prod.outlook.com>
 <89d77c3c-593b-b5dd-f39c-009575e295a5@gmail.com>
 <DM6PR07MB66183421EB52AD2928C6C365F9500@DM6PR07MB6618.namprd07.prod.outlook.com>
Date: Sun, 30 Aug 2020 19:02:54 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Proposal:_Adding_functions_any(iterable_$input,_?=
 =?UTF-8?Q?=3Fcallable_$cb_=3D_null,_int_$use=5Fflags=3D0)_and_all(...)?=
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Aug 30, 2020, at 3:43 PM, tyson andre wrote:
> Hi Dik Takken,
> 
> > I would love to see this come to PHP. I also do a lot of Python
> > development and I really like its operators module, which provides
> > function equivalents to the intrinsic Python operators. Have a look:
> > 
> > https://docs.python.org/3/library/operator.html
> > 
> > Although the any() and all() functions are my favorites, having the full
> > range of operator functions would be great. That could ultimately yield
> > a proper counterpart to the range of array_* functions which support any
> > iterable in stead of just arrays. Think of a keys() function that is a
> > generalization of array_keys().
> 
> Operator overloading was the subject of 
> https://wiki.php.net/rfc/userspace_operator_overloading#vote
> which had a 38-28 vote, which didn't meet the 2/3 voting threshold.
> 
> > This reminds me of the iter library that Nikita created:
> > 
> > https://github.com/nikic/iter
> > 
> > So yes, this can also be done in user space. Having it built into the
> language has advantages though:
> > 
> > * High adoption rates, making lots of existing PHP code more concise
> > * Possibly better performance
> 
> Strangely, if I remember correctly, I've had better performance looping 
> inline and calling closures than calling array_map
> when there were a large number of elements. I think opcache's 
> inferences and the fact there's no switch
> from internals back to the php vm was part of the reason for it.
> (and the tracking of stack frames?)
> 
> The readability's my main reason for making it native. I'd wondered if 
> there'd be a benefit to preloading where we replace C functions with 
> native php functions (optionally JITted) if there's an expected benefit,
> like HHVM does for parts of its standard library, but again out of 
> scope.
> 
> > Regarding performance: Since we already have opcodes for handling
> > operators, it may be possible to extend these to consume arbitrary
> > numbers of operands from iterables. Then, an operator function like
> > any() would compile into its equivalent operator opcode. Finally, that
> > opcode can probably be JIT compiled into a tight loop in machine code.
> 
> That's definitely something I'd want to see for array_map/array_filter.
> There's the question of whether it'd be reasonable to omit stack frames 
> or whether it's practical to create fake frames with parameter values
> for debug_backtrace().
> 
> Larry Garfield also did some work on python-like list comprehensions,
> though it's still in draft.
> Automatically rewriting array_map(), array_filter(), all(), etc. to 
> list comprehensions and then to JITted code
> could see a nice performance benefit in benefit, but this is out of 
> scope of the RFC I'm working on
> See https://externals.io/message/104637

I was just considering mentioning that. :-)  I still would like to see comprehensions happen, but I'd need to partner with someone with more engine skill than I to actually implement it, plus the reception was somewhat lukewarm.  I do think they're useful and would help with any/all/first type use cases, though.

If someone reading this is interested, you know where to find me...

--Larry Garfield