Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119740
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-221-gec32977366-fm-20230306.001-gec329773
Mime-Version: 1.0
Message-ID: <a3cebedb-05b7-49d4-9af0-499cfdf838cc@app.fastmail.com>
In-Reply-To: 
 <CABdc3WrcpPT-HMtren5n_=M5dWiSKywzsz3ht8vbCUsgc++dfw@mail.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>
 <73033e11-a521-40a3-a29e-14d575332aea@app.fastmail.com>
 <CABdc3WrcpPT-HMtren5n_=M5dWiSKywzsz3ht8vbCUsgc++dfw@mail.gmail.com>
Date: Fri, 17 Mar 2023 09:45:18 -0500
To: "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: larry@garfieldtech.com ("Larry Garfield")

On Fri, Mar 17, 2023, at 3:54 AM, Micha=C5=82 Marcin Brzuchalski wrote:

>> 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 =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 hig=
her
>> order functions for more control.
>>
>
> Maybe we could introduce two additional methods on a Closure similar to
> what Java have
> https://docs.oracle.com/javase/8/docs/api/java/util/function/Function.=
html
> * andThen() - which functionality is like a pipe operator
> * apply() - which you can call without the option to bind/rebind and j=
ust
> pass arguments for execution
>
> The pipe operator can be introduced later, but we could already have t=
he
> functionality on Closure.
>
> The above example might look readable as well:
>
> $size =3D amap(...)->partial(chr(...))
>     ->andThen(implode(...)->partial(','))
>     ->andThen(length(...))
>     ->apply($arr);

See that brings up a subtle difference between two operations: pipe and =
compose.

Compose takes two functions A and B and returns a new function that is l=
ogically identical to B(A()).  (Or sometimes A(B()), depending on the la=
nguage, which is all kinds of confusing.)

Pipe takes an arbitrary value and unary function and calls the function =
with that value immediately, returning the result.

You can build a pipe equivalent out of compose, although it's a bit clun=
ky and the semantics are not *quite* identical.  (The order of execution=
 is different, which may or may not matter depending on the specifics of=
 each call.)

In the example above, andThen() is acting as a compose operator, while a=
pply() is just boring function application.  It works but it's a bit clu=
nky compared to a proper pipe.  That said, there are user space librarie=
s that do that.

Thinking aloud...  I said before it would be better to have a native ope=
rator for all of these.  (compose, pipe, and partial.)  If we restrict o=
urselves to Closure objects rather than all callables (since callables a=
re a lot messier), that does open up some new options.  Specifically, th=
e following are already syntax errors today:

$c =3D strlen(...);
$d =3D array_map(...);

$c + $d; // not allowed.
$c . $d; // not allowed, thinks it's string concat and $c isn't stringab=
le.
$c[2, 3]; // not allowed.
$c{5}; // not allowed, thinks it's a string offset.

So that suggests to me the following:

* Define $a + $b on closure objects to be a compose operator that return=
s a new function equivalent to $b($a( )).  It would only work on unary f=
unctions, validate compatible types between the param and return values,=
 and have the correct type information.

* Define $c{ ... } as a "partial application" call.  The {} body would b=
e similar to a function call now; or maybe the original PFA syntax with =
? and ... ?  Debatable, but the {} would be a better signal to the engin=
e that we're not calling a function, just partially calling.  It's also =
reasonably self-evident to developers.

Those two together would allow for this:

(amap{chr(...), ?} + implode{?, separator: ','} + length(...))($arr);

Which is... pretty nice, really.  It's very close to the original PFA sy=
ntax and capabilities, compact, not easily confused with anything else, =
type safe, and the engine can handle optimizing around not having unnece=
ssary interstitial functions internally.

I still think we should also add a pipe operator |> as well, but that wo=
uld be just as compatible with the {}-based PFA syntax.  It's also fairl=
y trivial to implement.

$size =3D $arr
  |> amap{chr(...), ?)
  |> implode(',', ?)
  |> length(...);

Thoughts?

--Larry Garfield