Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115197
MIME-Version: 1.0
In-Reply-To: <bd6cabb6-339a-46ca-8d50-f595f951ad58@www.fastmail.com>
References: <d50eaa78-21c7-46e7-9da6-629ba5694d3f@www.fastmail.com>
 <CAJpLVh0Fo9odHeO_CoSxCKA+2dELhG7-H9BvY--tfd59q0iXhQ@mail.gmail.com>
 <b256ac45-e893-90b9-70ba-89fd326c1cf7@gmail.com> <43d612c0-7462-463a-9536-ed5b66d9ae1e@www.fastmail.com>
 <CAJpLVh1MUTi0b4HiHXEAfjeKvQXranwsdX9S8QagFYYEfn-9Jg@mail.gmail.com> <bd6cabb6-339a-46ca-8d50-f595f951ad58@www.fastmail.com>
Date: Tue, 29 Jun 2021 00:30:50 +0200
Message-ID: <CAJpLVh1JXStoumLrLTJwA7ouvgkkBoot6yu-7f=LeLC6G5spDQ@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] [RFC] Pipe Operator, take 2
From: olleharstedt@gmail.com (=?UTF-8?Q?Olle_H=C3=A4rstedt?=)

2021-06-28 23:36 GMT+02:00, Larry Garfield <larry@garfieldtech.com>:
> On Mon, Jun 28, 2021, at 3:42 PM, Olle H=C3=A4rstedt wrote:
>> 2021-06-28 22:12 GMT+02:00, Larry Garfield <larry@garfieldtech.com>:
>> > On Mon, Jun 28, 2021, at 3:04 PM, Rowan Tommins wrote:
>> >> On 28/06/2021 20:25, Olle H=C3=A4rstedt wrote:
>> >> > Usage (ignoring the pesky undefined constant warnings ><):
>> >>
>> >>
>> >> Unfortunately, you can't ignore those warnings; not least because
>> >> they're fatal errors in PHP 8, as they frankly should have been in PH=
P
>> >> 3.
>> >>
>> >> You can use our current ugly callable syntax (strings and two-element
>> >> arrays); you can tackle the complexity of unifying functions with
>> >> constants, and methods with properties (as Levi explained in the othe=
r
>> >> thread); or you can add a dedicated callable syntax, which the PFA
>> >> proposal gets us with bells on.
>> >>
>> >> Regards,
>> >
>> > I think that's a pretty good summary.  There's nothing that pipes or
>> > partials do that you couldn't emulate in user-space today (really, sin=
ce
>> > 5.3
>> > is you really wanted to).  The emulation is just butt-ugly and slower,
>> > which
>> > is why most people don't do it except in very specific cases or if the=
y
>> > have
>> > a user-space library available that makes it slightly less butt-ugly.
>> >
>> > The purpose of PFA and pipes (and short functions, and auto-capture
>> > closures, and basically everything else I've been talking about all
>> > year) is
>> > to make those things prettier and as fast as reasonable, which makes
>> > using
>> > those techniques more natural.  Once you start down that path, though,
>> > there's really no usable solution before you get down as far as... PFA
>> > and
>> > Pipes in their current form.
>> >
>> > --Larry Garfield
>>
>> The challenge is to write something that's pretty enough to be
>> considered idiomatic. :) The pipe operator in OCaml is defined by one
>> line:
>>
>>     let (|>) v f =3D f v
>>
>> It wasn't always part of core, but eventually it was so common, it got
>> included by default. Same could happen with a pipe() function in PHP,
>> without the pipe operator, or that the function becomes so common, a
>> new keyword is added instead: `pipe`. But it could probably not happen
>> with a Pipe object requiring you to write ->pipe() at every step -
>> it's too much ceremony and boilerplate.
>>
>> By the way, that's alternative 5) New keyword `pipe` to make the
>> warning about constants shut up in a certain scope. Plus some other
>> magic to allow nice chaining. ^^
>>
>> Olle
>
> "Idiomatic PHP" consists primarily of associative arrays, used in ways no
> sane person would ever use a dictionary, but the code is in a method so i=
t
> gets called OOP even though it's barely procedural.
>
> That's not an idiom I have any interest in supporting, and have in fact m=
ade
> a career out of training people out of. :-)
>
> There are *already* libraries that let you write ->pipe().  The PHP Leagu=
e
> has one, for instance:
>
> https://github.com/thephpleague/pipeline
>
> I've seen others, but they're no less ugly and offer no better migration
> path into a core syntax.  PHP is just not designed as a user-extensible
> language.  (cf, "Growing a Language" by Guy Steele, one of the best
> presentations ever given: https://www.youtube.com/watch?v=3D_ahvzDzKdB0)
>
> Also of note, the OCaml definition there is almost exactly the same as th=
e
> current patch; there's a request out I'm working on now to change the
> implementation to ensure that the LHS is fully evaluated before the RHS, =
but
> it's interesting to see that OCaml's version does have the out-of-order
> challenge.  (Although in a functional language it's semantically a
> meaningless difference, by design.)
>
> Overall, I really don't like the idea of special-casing pipes to change w=
hat
> symbol table gets looked up.  That's just asking for edge cases to bite u=
s
> later, especially when the root problem isn't with pipes in the first pla=
ce;
> it's with PHP lacking either a function-reference syntax or PFA (which gi=
ves
> us a function-reference syntax for free).  Fix the real problem, don't ha=
ck
> around it in what should be a very simple feature.
>
> --Larry Garfield

Mm. Assoc arrays are by now known to be not so good. I hope...

OCaml is strictly evaluated, not lazy like Haskell. So the order might
matter, dunno, I don't use this operator often. :) My point was mostly
that it's very easy to add in OCaml - just one line. And as in
Haskell, you can define operators in your modules. Similarly, in PHP
it's easy to do super-dynamic stuff like "new $someclass", which is
not remotely possible in FP (good or bad, depending on your religion).

Adding a new pipe keyword is like the list() keyword, kind of. A bad
idea, haha. But I think all stones can be turned, if this RFC now gets
a no. :/

Would a slimmed down version have more support? How about removing the
variadic operator, and let the user manually add the lambda for those
cases? Could reduce the complexity while still covering maybe 80% of
the use-cases? Same with removing support for named arguments. So '?'
would only be a short-cut to get rid of boilerplate like `$strlen =3D
fn($x) =3D> strlen($x)`.

> Overall, I really don't like the idea of special-casing pipes to change w=
hat
> symbol table gets looked up.

Still wondering if this could be a per-file or per-library setting
somehow, to opt-in into pipe behaviour when so desired. Or rather, to
opt-in into this or that behaviour needed to do more idiomatic pipe.

Here's one boilerplaty pipe:

// Original snippet with nested calls and hard-to-follow program flow
$result =3D array_filter(
    array_map(
        'strtoupper',
        str_split(
            htmlentities("Hello World")
        )
    ),
    fn($v) =3D> $v !=3D=3D 'O'
);

// Boilerplate setup
$htmlentities =3D fn($x) =3D> htmlentities($x);
$str_split    =3D fn($x) =3D> str_split($x);
$strtoupper   =3D fn($x) =3D> strtoupper($x);

// Actual calculation
$result =3D pipe(
    "Hello world",
    $htmlentities,
    $str_split,
    fn ($x) =3D> array_map($strtoupper, $x),
    fn ($x) =3D> array_filter($x, fn ($v) =3D> $v !=3D=3D 'O')
);

Where pipe() is just:

function pipe() {
    $args =3D func_get_args();
    $result =3D $args[0];
    $functions =3D array_slice($args, 1);
    foreach ($functions as $function) {
        $result =3D $function($result);
    }
    return $result;
}

Olle