Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119735
MIME-Version: 1.0
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> <73033e11-a521-40a3-a29e-14d575332aea@app.fastmail.com>
In-Reply-To: <73033e11-a521-40a3-a29e-14d575332aea@app.fastmail.com>
Date: Fri, 17 Mar 2023 10:52:37 +0100
Message-ID: <CAPzBOBPDS-z7vM_99ooKKedzTr_P4wN+-TA40ECotGgE8tBZpQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] First-class callable partial application
From: landers.robert@gmail.com (Robert Landers)

On Thu, Mar 16, 2023 at 11:26=E2=80=AFPM Larry Garfield <larry@garfieldtech=
.com> wrote:
>
> 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 instanc=
e
> > method on Closure would allow this:
> >
> > $mapFoo =3D array_map(...)->partial([$foo]);
> > $filterFoo =3D array_filter(...)->partial([1 =3D> $foo]);
> >
> > Which could copy over the full signature, so be equivalent to this:
> >
> > $mapFoo =3D static fn(array ...$arrays): array =3D> array_map($foo, ...=
$arrays);
> > $filterFoo =3D static fn(array $array, int $mode =3D 0): array =3D>
> > array_filter($array, $foo, $mode);
> >
> > While being a similar length to a much less rich version:
> >
> > $mapFoo =3D fn($array) =3D> array_map($foo, $array);
> > $filterFoo =3D fn($array) =3D> 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 th=
e advantage of the implementation almost certainly being rather pedestrian =
in comparison.  That approach would favor left-to-right application, but no=
t force it, which is probably sufficient.
>
> As a thought experiment, if we had that syntax and functions that were de=
signed 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 =3D [1, 2, 3];
>
> $a2 =3D amap(...)->partial(chr(...))($arr);
>
> $str =3D implode(...)->partial(',')($a2);
>
> Or, if combined with pipes:
>
> $size =3D $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 onl=
y 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 object=
s?
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Hey Larry,

> We would likely want partial() to accept positional args (left to right) =
and named args.

I think this is already supported-ish. For example, here's a partial
application in user space that seems to follow all the rules. Or at
least the rules that are followed make sense.

function partial(Closure $callable, ...$args): Closure {
   return static fn(...$fullArgs) =3D> $callable(...[...$args, ...$fullArgs=
]);
}

https://onlinephp.io/c/9195a

It only needs a bit of edge-condition handling (like when a parameter
is filled, you probably shouldn't be able to override arbitrary
parameters).