Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114551
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> <CAOWwgp=QZ0jAy4Qc+w7grEEN0b9KCX+Uec12AQoYPQHTqQ-Ddg@mail.gmail.com>
In-Reply-To: <CAOWwgp=QZ0jAy4Qc+w7grEEN0b9KCX+Uec12AQoYPQHTqQ-Ddg@mail.gmail.com>
Date: Fri, 21 May 2021 09:52:18 +0200
Message-ID: <CAOWwgpmQeN9J9pTOenTrSngzWAN_P6XRf4Z1CNrSmDFGHjtsRg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000071f8df05c2d25773"
Subject: Re: [PHP-DEV] [RFC] First-class callable syntax
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--00000000000071f8df05c2d25773
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Sorry for self-reply, this needs some clarifications :)

Le ven. 21 mai 2021 =C3=A0 09:17, Nicolas Grekas <nicolas.grekas+php@gmail.=
com>
a =C3=A9crit :

> 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 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
>> 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
>> 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)?
>> >
>> > 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 paramete=
rs
>> 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 key=
s
>> 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.
>

I'm talking about implicit extra arguments accessed via func_get_args()
here.

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.
>

Reading your gists, I'm with drawing this expectation.

Since calls reorder named arguments automatically, we could expect the same
for PFAs.
That is:
since foo(A: 1, B: 2) is exactly the same as foo(B: 2, A: 1)
we could also expect that foo(A: ?, B: ?) would be exactly the same
foo(B:?, A:?)

The issue here is that the syntax can be interpreted as both a new
signature and as a partial call.
If we stay pure to the intend of PFAs, argument reordering shouldn't be
allowed IMHO. Aka this should be interpreted only as a partial call.

*If* we need a way to reorder arguments, I think it would be natural also
to be able to *rename* arguments.

That's where my syntax proposal based on short closures might be handy:

fn($a, $b, ...) =3D> $callable($b, a: $a, ...)



>
>
>> We also went down a rabbit hole of trying to make argument reordering
>> work 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 woul=
d
> keep this possibility open of the future and close the "principle of leas=
t
> surprise" expectation if there are. Aka foo(bar: ?) should be a parse err=
or
> 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 RF=
C
>> here would be an improvement over 8.0, I don't think throwing in the tow=
el
>> on PFA yet is a good idea.  It's a much more robust and powerful approac=
h
>> that still gets us the "first class callable" syntax we all want (at lea=
st
>> I assume we all do), and lots of additional power to boot.  I'd rather s=
ee
>> us try to drive PFA home to completion.  If that proves impossible by ea=
rly
>> 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 sorte=
d
>> 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
>

--00000000000071f8df05c2d25773--