Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115202
MIME-Version: 1.0
In-Reply-To: <13476e3c-93d6-4c6f-be9e-24f46a5049fb@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> <CAJpLVh1JXStoumLrLTJwA7ouvgkkBoot6yu-7f=LeLC6G5spDQ@mail.gmail.com>
 <13476e3c-93d6-4c6f-be9e-24f46a5049fb@www.fastmail.com>
Date: Tue, 29 Jun 2021 10:25:42 +0200
Message-ID: <CAJpLVh23D_ky-u43xpdAvn7XDMoLrJ_46LPkRL0VkceyDHFTqw@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-29 0:54 GMT+02:00, Larry Garfield <larry@garfieldtech.com>:
> 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).
>>
>> 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)`.
>
> I talked with Joe about this, and the answer is no.  Most of the complexi=
ty
> comes from the initial "this is a function call, oops no, it's a partial
> 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, supporting o=
ne
> placeholder or multiple, variadics or not, etc. is only a small increment=
al
> increase in complexity.
>
>> > Overall, I really don't like the idea of special-casing pipes to chang=
e
>> > what
>> > 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:
>
> *snip*
>
> We're in the pipe thread here, not PFA. :-)  And really, you're solving t=
he
> wrong problem.  Pipes are trivial.  They're only clunky because of PHP'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 worki=
ng
> PFA RFC that's about to end voting.  (And right now is losing by a very s=
lim
> margin, but could pass if a few people change their minds.)
>
> Aside from something like Nikita's ...-only function reference RFC, which
> only handles half the problem (it doesn't do anything to make multi-arg
> 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-spa=
ce
> 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 ba=
ck
> to the uglier version without PFA, and yeah, it's not going to look as
> pretty.  And the main pushback a year ago when I first brought it up was
> "PFA first, please, so the callable syntax isn't ugly."  And... here we
> are.
>
> --Larry Garfield

Is there no "pre-vote" process for RFCs? For example, letting the
voting members *rate* different alternatives, in a ranking fashion, to
see which one is most and least popular. Feels like a lot of work is
getting wasted if something is voted down on a small margin.

Olle