Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120845
MIME-Version: 1.0
In-Reply-To: <014c449a-fa84-4fa2-bfec-518a8fdb4ff1@app.fastmail.com>
References: <CAOfzkkxrQOje274RMUW8kv13vBmtNSNd_D9Bq_SJeDEBVA8i7Q@mail.gmail.com>
 <CAJpLVh1hhd=zxSz+T4eZdd7eBD-40muU81eFwhmh3e0n7VGwyQ@mail.gmail.com>
 <8055b366-32f1-4d2c-85d0-0cf665e6c8d3@app.fastmail.com> <CAJpLVh2t5Y7CzYTJZxLViCYpgncuJg3i4v==q1gye1m-iR4QPQ@mail.gmail.com>
 <e70f5b7f-3911-4f0b-9942-3e825e7bf89c@app.fastmail.com> <CAJpLVh0BAwetczZpiPDUvsH3AgUPgj5nrZbvjYd0y1iWvi8bRg@mail.gmail.com>
 <CAOfzkkyKnCz0yfMH_PNMSjfs+mU3zSHhJ2uaguuSVNjARA09TQ@mail.gmail.com>
 <fa5c8d8b-5573-48ef-92bf-642b84fcbfbd@app.fastmail.com> <CAOfzkkzdOwBEJR2xmH8+5QF=Z1FgJXnQYLM+BQwbnOws=E0zCA@mail.gmail.com>
 <014c449a-fa84-4fa2-bfec-518a8fdb4ff1@app.fastmail.com>
Date: Tue, 18 Jul 2023 21:18:58 +0200
Message-ID: <CAJpLVh1am6VV6c_C+X3QyYpzxGS=sMG8_hu_H5jU_RDcDUtf8w@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] pipes, scalar objects and on?
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2023-07-18 20:08 GMT+02:00, Larry Garfield <larry@garfieldtech.com>:
> On Tue, Jul 18, 2023, at 5:08 PM, Karoly Negyesi wrote:
>> My favorite pipeline is Elixir, where "The pipe operator |> passes the
>> result of an expression as the first parameter of another expression"..
>> But
>> it works there because unlike with PHP, it's almost always the first
>> argument you want. If it's not the first argument you needed to do some
>> tricks which was only cleaned up in 2021 so now they do:
>>
>> 5
>> |> then(&Enum.take(1..10, &1))
>> |> Enum.reverse()
>>
>> but I digress.
>>
>> My problem here is... we actually need something that passes the RFC
>> vote.
>>
>> What flexibility is missing here?
>
> Please don't top post.
>
> The main flexibility for callables is the ability to build a closure on the
> fly.  For example, using $$ (which Hack does, and I insist on calling
> T_BLING) means that for array and string functions you still need to worry
> about parameter order.  With a callable, you can effectively emulate
> Elixir's behavior if you want.
>
> For example, my FP library has a whole bunch of higher order functions that
> just return pipe-ready functions:
>
> https://github.com/Crell/fp/blob/master/src/array.php
>
> Which, with a pipe operator, would allow for:
>
> $result = $arr
>   |> amap(trim(...))
>   |> afilter(is_int(...))
>   |> reduce(0, $fn)
>   |> trim(...) // At this point it's a string and trim() is already unary,
> so we can just use it.
> ;
>
> Which is pretty nice, IMO.  It "flows" nicely, supports both higher order
> functions and direct calls equally well, and allows for all kinds of further
> expansion that I haven't thought of yet.
>
> The Hack style would require thinking about the fact that array_map() and
> array_filter() take their arguments in reverse order from each other, which
> is just silly.  This way, that problem goes away entirely.
>
> It also allows a pipe to be used as a quasi alternative to scalar methods,
> because (if we set aside visibility for the moment) a method is just a
> function with an implicit $this parameter.  Callables and higher order
> functions make that a lot cleaner.
>
> The caveat is that it does add an extra step to use many of the existing
> array or string stdlib functions.  However, that's work that can be done
> once.  The link above is under 500 lines, heavily documented, and covers
> every array use case I've run into so far.
>
> Related improvements:
>
> * Writing a higher order function right now is rather cumbersome.  There
> were two previous RFCs that would have made that vastly nicer
> (short-functions and auto-capture closures), but neither passed.  They would
> have allowed for:
>
> function amap(callable $c) => fn (iterable $it): array {
>     if (is_array($it)) {
>         return array_map($c, $it);
>     }
>     $result = [];
>     foreach ($it as $k => $v) {
>         $result[$k] = $c($v);
>     }
>     return $result;
> };
>
> Which I think is pretty nice.
>
> * PFA would give us the best of both worlds, as if you wanted you could do:
>
> $result = $arr
>   |> array_map(trim(...), ?)
>   |> array_filter(?, is_int(...))
>   |> array_reduce(?, $fn, 0)
>   |> trim(...)
> ;

Damn, that PFA RFC would _really_ help with removing noise, instead of
wrapping with fn ($x) => ... everywhere. Shame it didn't pass. :/ 29
vs 20 votes.

Olle