Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119731
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-221-gec32977366-fm-20230306.001-gec329773
Mime-Version: 1.0
Message-ID: <73033e11-a521-40a3-a29e-14d575332aea@app.fastmail.com>
In-Reply-To: <f4c5b39f-1911-8e47-3f07-58f8ae7fd33e@gmail.com>
References: 
 <CAM0CcxhpMr_SstLCgcMfESTo4_H6yAPuBZb6B08KjbnKS97VfA@mail.gmail.com>
 <9975B833-EE24-4ED7-B28E-841B92988BA0@cschneid.com>
 <CAPzBOBPP8xy6S4nv2i8t1bgPj0hvFw4seBQ31QFSpA9aeAPyAA@mail.gmail.com>
 <CALKiJKoW0obHeG+53Yai25BHVDiscW6X7pn-uH+OLBDvvDQJ8Q@mail.gmail.com>
 <CAPzBOBMVnACDUrH=jCKPSNonzcv3Zm4J5yr5h1vVXHVOi872mA@mail.gmail.com>
 <1A2CE63B-ECCA-403D-83AC-B1E26279323C@gmail.com>
 <9a2140b4-97bb-4a9c-90c5-809274c83f75@app.fastmail.com>
 <88c4a63c-859b-94d5-e314-3399fb2c3fb0@gmail.com>
 <AM8P250MB017093F4BFE7C9E7B63AEF9CE2BE9@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <CALKiJKqf5WqYw8qS=3-OQW_s02_7THr6FMP99USJfnNFpwvFDQ@mail.gmail.com>
 <CAPzBOBNGRiT6Y5grn7FHSu9xEsqqdHEeMW1dvuQCV30sf5wE2w@mail.gmail.com>
 <1a4d4434-7318-4831-9fc0-8b48a6400a62@app.fastmail.com>
 <CA+kxMuTXzYcWx_pcsqniv23+Qq_r_t9339eNWmYk_agZx9rj=w@mail.gmail.com>
 <f4c5b39f-1911-8e47-3f07-58f8ae7fd33e@gmail.com>
Date: Thu, 16 Mar 2023 17:26:00 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] First-class callable partial application
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Mar 16, 2023, at 4:14 AM, Rowan Tommins wrote:
> On 15/03/2023 21:12, Dan Ackroyd wrote:
>> Would it be desirable to split those two things into two separate
>> RFCs, by having the first RFC not have native syntax support, but
>> instead another static method on Closure? e.g. something like:
>>
>> Closure::partial($callable, array $position_params, array
>> $named_params): Closure {}
>
>
> Hm... now we have the first-class callable syntax, making it an instance 
> method on Closure would allow this:
>
> $mapFoo = array_map(...)->partial([$foo]);
> $filterFoo = array_filter(...)->partial([1 => $foo]);
>
> Which could copy over the full signature, so be equivalent to this:
>
> $mapFoo = static fn(array ...$arrays): array => array_map($foo, ...$arrays);
> $filterFoo = static fn(array $array, int $mode = 0): array => 
> array_filter($array, $foo, $mode);
>
> While being a similar length to a much less rich version:
>
> $mapFoo = fn($array) => array_map($foo, $array);
> $filterFoo = fn($array) => array_filter($array, $foo);

Fascinating!  I... don't know if we considered something like that or not 3 years ago.  It's been a while.

It's definitely not as nice as the integrated syntax, but it does have the advantage of the implementation almost certainly being rather pedestrian in comparison.  That approach would favor left-to-right application, but not force it, which is probably sufficient.

As a thought experiment, if we had that syntax and functions that were designed to be used with them, it would look like so:

function amap(callable $c, iterable $it) { ... }
function implode(string $sep, iterable $it) { ... }
function length(string $s) { ... }

$arr = [1, 2, 3];

$a2 = amap(...)->partial(chr(...))($arr);

$str = implode(...)->partial(',')($a2);

Or, if combined with pipes:

$size = $arr 
|> amap(...)->partial(chr(...))
|> implode(...)->partial(',')
|> length(...);

Which... is not terrible, especially as it doesn't preclude using higher order functions for more control.  

We would likely want partial() to accept positional args (left to right) and named args.  And I'm more than happy to say now that the capture is only by value, ever.

I wonder if there's a shorter name we could use than "partial" to make it more readable?  Or perhaps an operator that applied only to closure objects?  

--Larry Garfield