Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115199
User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578
Mime-Version: 1.0
Message-ID: <13476e3c-93d6-4c6f-be9e-24f46a5049fb@www.fastmail.com>
In-Reply-To: 
 <CAJpLVh1JXStoumLrLTJwA7ouvgkkBoot6yu-7f=LeLC6G5spDQ@mail.gmail.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>
 <CAJpLVh1JXStoumLrLTJwA7ouvgkkBoot6yu-7f=LeLC6G5spDQ@mail.gmail.com>
Date: Mon, 28 Jun 2021 17:54:14 -0500
To: "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: larry@garfieldtech.com ("Larry Garfield")

On Mon, Jun 28, 2021, at 5:30 PM, Olle H=C3=A4rstedt wrote:

> Mm. Assoc arrays are by now known to be not so good. I hope...

There are millions of PHP sites build on anonymous arrays today.

> 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).=

>=20
> 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. :/
>=20
> 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)`.

I talked with Joe about this, and the answer is no.  Most of the complex=
ity comes from the initial "this is a function call, oops no, it's a par=
tial call so we switch to doing that instead", which ends up interacting=
 with the engine in a lot of different places.  Once you've done that, s=
upporting one placeholder or multiple, variadics or not, etc. is only a =
small incremental increase in complexity.

> > Overall, I really don't like the idea of special-casing pipes to cha=
nge what
> > symbol table gets looked up.
>=20
> 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.
>=20
> Here's one boilerplaty pipe:

*snip*

We're in the pipe thread here, not PFA. :-)  And really, you're solving =
the wrong problem.  Pipes are trivial.  They're only clunky because of P=
HP's lack of decent callable syntax.  PFA gives us that, but the engine =
makes the implementation more complex than it seems like at first glance=
.

Trying to come up with complex workarounds to make pipes pretty without =
helping anything else is a fool's errand, especially when we have a work=
ing PFA RFC that's about to end voting.  (And right now is losing by a v=
ery slim margin, but could pass if a few people change their minds.)

Aside from something like Nikita's ...-only function reference RFC, whic=
h only handles half the problem (it doesn't do anything to make multi-ar=
g functions work with pipes at all), any other solution is going to end =
up reinventing PFA one way or another, or reinventing existing ugly user=
-space libraries. one way or another

I've not yet decided if I'm going to bring pipes to a vote if PFA doesn'=
t pass.  I'm tempted to, but it would require rewriting all the RFC text=
 back to the uglier version without PFA, and yeah, it's not going to loo=
k as pretty.  And the main pushback a year ago when I first brought it u=
p was "PFA first, please, so the callable syntax isn't ugly."  And... he=
re we are.

--Larry Garfield