Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114545
User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416
Mime-Version: 1.0
Message-ID: <fa269b69-9bac-4a81-8c65-409766f1c9f8@www.fastmail.com>
In-Reply-To: 
 <CAC5V6ghco1H4jT2Y_ug3LTWfyAz_5f6iCObGrdDfXn2PeuXgLg@mail.gmail.com>
References: 
 <CAF+90c_iYjsDWoqPaDtavVgj2WFdpiuBmGeQZFAqokVoVZTxoA@mail.gmail.com>
 <CALfTnfXDTvrtA9-hN+UH+qs3iS9q34jseunBD7YumGkonrSwXA@mail.gmail.com>
 <CAF+90c9DpTWzqu9S9=CkuaW=RnbneXUbRbqhuJDRBPwUz9RMsA@mail.gmail.com>
 <CAC5V6ghco1H4jT2Y_ug3LTWfyAz_5f6iCObGrdDfXn2PeuXgLg@mail.gmail.com>
Date: Thu, 20 May 2021 14:35:35 -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] First-class callable syntax
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, May 20, 2021, at 10:55 AM, Guilliam Xavier wrote:
> On Thu, May 20, 2021 at 5:12 PM Nikita Popov <nikita.ppv@gmail.com> wr=
ote:
>=20
> > On Thu, May 20, 2021 at 4:16 PM Ond=C5=99ej Mirtes <ondrej@mirtes.cz=
> wrote:
> >
> > > Hi, I=E2=80=99m confused by the syntax, when I read it, I think to=
 myself =E2=80=9CI know
> > > this, this is just a method call=E2=80=A6 oh wait, it=E2=80=99s ac=
tually a callable=E2=80=9D. It
> > > really makes my head hurt.
> > >
> >
> > Yes, I can see how that could be confusing. The current syntax is ch=
osen to
> > be a subset of the partial function application proposal. However, I=
 would
> > also be happy with some other syntax that makes it clearer that this=
 is
> > acquiring a callable and not performing a call.
> >
>=20
> Hi, several other syntaxes have been proposed to consideration in the =
PFA
> thread, and I wouldn't want to start new bikeshedding here; is there a=

> place that would be more appropriate to gather the possibilities (like=
 a
> kind of updatable list)?
>=20
> Thanks,

There's been a lot of rapid iteration, experimentation, and rejection.  =
The most recent alternatives are this one from Levi:

https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbfd

And this one from me:

https://gist.github.com/Crell/ead27e7319e41ba98b166aba89fcd7e8

The main takeaways (to give context to Nikita's proposal):

* Because of optional arguments, using the same symbol for "copy one par=
ameter from the underlying function" and "copy all remaining parameters =
from the underlying function" is not viable.  It runs into oddball cases=
 where you may intend to only use one argument but end up using multiple=
, especially in array operation functions that sometimes silently pass k=
eys along to callbacks if they can.  Hence the separate ? and ... that w=
ere proposed.

* Named arguments make things more complicated.  One of the questions is=
 whether named placeholders should be supported or not.  And if they are=
, does that mean you can effectively reorder the arguments in the partia=
l application, and what does that mean for usability.  It gets complicat=
ed and scope-creepy fast.

* The most important use cases are:
** "prefill nothing, just give me a callable" (which is the case Nikita'=
s RFC covers)=20
** "reduce an arbitrary function to a single remaining argument", which =
lets it be used by various existing callback functions in the standard l=
ibrary (array_map, array_filter, etc.), many user-space APIs, and the pi=
pes RFC that I am planning to bring back up once PFA is figured out (htt=
ps://wiki.php.net/rfc/pipe-operator-v2). =20

While there are other use cases, the two of those cover the vast majorit=
y of uses.  (There is some dispute about which of those is larger, or wi=
ll be larger in the future.)

It took a while to realize the first point, which basically killed "? me=
ans zero or more".  We also went down a rabbit hole of trying to make ar=
gument reordering work because some people asked for it, but as noted th=
at's a very deep rabbit hole.

My gist above was a reduced-scope version of Levi's that uses two symbol=
s and drops named placeholders.  It doesn't give us every possible combi=
nation, but it does give us most reasonable combinations.

Nikita's "just do the first one" RFC (this thread) was proposed at about=
 the same time, and takes an even-further scope reduction.

My own take is that the PFA discussion has been overly-bikeshedded, whic=
h is unfortunate since I think we're quite close to now having a workabl=
e answer that covers most reasonable use cases.  While I agree Nikita's =
RFC here would be an improvement over 8.0, I don't think throwing in the=
 towel on PFA yet is a good idea.  It's a much more robust and powerful =
approach that still gets us the "first class callable" syntax we all wan=
t (at least I assume we all do), and lots of additional power to boot.  =
I'd rather see us try to drive PFA home to completion.  If that proves i=
mpossible by early July, then this RFC would still get us something this=
 cycle, as long as the syntax is still compatible with PFA.  (Otherwise =
whenever PFA gets sorted out in the future we end up with yet-more-ways =
to do the same thing that are not optimizations of each other but just c=
ompeting syntax, in which case no one wins.)

--Larry Garfield