Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114550
MIME-Version: 1.0
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> <fa269b69-9bac-4a81-8c65-409766f1c9f8@www.fastmail.com>
In-Reply-To: <fa269b69-9bac-4a81-8c65-409766f1c9f8@www.fastmail.com>
Date: Fri, 21 May 2021 09:17:58 +0200
Message-ID: <CAOWwgp=QZ0jAy4Qc+w7grEEN0b9KCX+Uec12AQoYPQHTqQ-Ddg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ac993905c2d1dc16"
Subject: Re: [PHP-DEV] [RFC] First-class callable syntax
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000ac993905c2d1dc16
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you all for your efforts, I think we're almost there and that PFA
would be a really great and useful addition to the language.

Le jeu. 20 mai 2021 =C3=A0 21:38, Larry Garfield <larry@garfieldtech.com> a
=C3=A9crit :

> 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>
> wrote:
> >
> > > 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 act=
ually a
> callable=E2=80=9D. It
> > > > really makes my head hurt.
> > > >
> > >
> > > Yes, I can see how that could be confusing. The current syntax is
> chosen 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.
> > >
> >
> > Hi, several other syntaxes have been proposed to consideration in the P=
FA
> > 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)?
> >
> > 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
> parameter from the underlying function" and "copy all remaining parameter=
s
> 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 keys
> along to callbacks if they can.  Hence the separate ? and ... that were
> proposed.
>

I've read that some ppl think this should be fought, but that's actually a
critical feature of the engine when writing BC layers by adding extra
arguments via this possibility.

In the 2nd gist, I read "If the current position is a ..., copy all
remaining parameters from the underlying function, including a variadic."
But to me it's important that all extra arguments are forwarded to the
partialized callable, where ... is used or not.
Please clarify this point if possible.

* 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 partial
> application, and what does that mean for usability.  It gets complicated
> and scope-creepy fast.
>

For the userland pov, the principle of least surprise would say we should
answer yes to both questions.


> We also went down a rabbit hole of trying to make argument reordering wor=
k
> because some people asked for it, but as noted that's a very deep rabbit
> hole.
>

Then maybe named args should be forbidden for "?" placeholders. This would
keep this possibility open of the future and close the "principle of least
surprise" expectation if there are. Aka foo(bar: ?) should be a parse error
for now at least.

My own take is that the PFA discussion has been overly-bikeshedded, which
> is unfortunate since I think we're quite close to now having a workable
> 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 towe=
l
> 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 want (at leas=
t
> I assume we all do), and lots of additional power to boot.  I'd rather se=
e
> us try to drive PFA home to completion.  If that proves impossible by ear=
ly
> July, then this RFC would still get us something this cycle, as long as t=
he
> 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 competing syntax, in which
> case no one wins.)
>

I agree. Let's figure out PFAs!

If I may add to the bikeshedding, and since PFAs are like others said
"short lambas on steroids", what about borrowing the syntax from them?

Here would be the first-class callable syntax:

fn(...) =3D> $callable(...)

and for PFAs:

fn(...) =3D> $callable(?, 42, ...)

Nicolas

--000000000000ac993905c2d1dc16--