Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114508
MIME-Version: 1.0
References: <f3d20496-c560-42b7-9a0d-8672b3cafa7d@www.fastmail.com>
 <1565EB81-57B7-49B0-A47C-342E0088A432@trowski.com> <CAN2symhHys1uADWnOfraEA3SiM8_57=JttWhgOJ0Kh7nwt4R+g@mail.gmail.com>
 <CAEMvS4FbtPqdeySsVWm=Gub1BNiv+OCiB2oGL-+aZvBH7hmisA@mail.gmail.com>
 <CAEMvS4F+AbxPJQ5ctLONptECvmkdrzT42oU4rDOjtD2dC_jEJw@mail.gmail.com>
 <09B663C3-E21D-432B-BB7F-78312F827C30@newclarity.net> <CAC5V6gjDfqxBPYF_ejVTboPOGV9rg0ArAqOGGO3mPG6nqEPevw@mail.gmail.com>
 <CAAKU0u=ssfSbHHdxgWgEHT0a+0iMKvdtJbWT6OFw9mNtfPWt4Q@mail.gmail.com>
 <CAC5V6gikd-vEmiY-XUH-CHPVEXBsLTebYho5H7880OWemy_-Zw@mail.gmail.com>
 <CAAwdEzBhR+hPLkRORa_pPZV-kqJdNNnJS23aPKjJ2xO-DKhU3g@mail.gmail.com> <CAC5V6ghuTwbZPcPUThWf+1LmHvRKB8ZvHJfTcgr1QMmmmioaFg@mail.gmail.com>
In-Reply-To: <CAC5V6ghuTwbZPcPUThWf+1LmHvRKB8ZvHJfTcgr1QMmmmioaFg@mail.gmail.com>
Date: Mon, 17 May 2021 21:51:02 +0300
Message-ID: <CAAwdEzD_4sykyODW=2qHN8BXcf-_SRiy+67zyjuYifZ=oOHzeQ@mail.gmail.com>
To: Guilliam Xavier <guilliam.xavier@gmail.com>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, Mike Schinkel <mike@newclarity.net>, 
	Hossein Baghayi <hossein.baghayi@gmail.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000006d22905c28b1420"
Subject: Re: [PHP-DEV] [RFC] Partial function application
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--00000000000006d22905c28b1420
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 17, 2021, 19:53 Guilliam Xavier <guilliam.xavier@gmail.com>
wrote:

>
>
> On Mon, May 17, 2021 at 5:47 PM Alexandru P=C4=83tr=C4=83nescu <drealecs@=
gmail.com>
> wrote:
>
>>
>> On Mon, May 17, 2021 at 6:36 PM Guilliam Xavier <
>> guilliam.xavier@gmail.com> wrote:
>>
>>> On Mon, May 17, 2021 at 5:01 PM Levi Morrison <
>>> levi.morrison@datadoghq.com>
>>> wrote:
>>>
>>> > Joe Watkins has successfully worked out some bugs that also enable
>>> > more powerful behavior. Thanks to Nikita and any others who worked
>>> > with Joe on fixing these issues and reviewing the PR.
>>> >
>>> > The short of it is that re-ordering parameters when using named
>>> > placeholders is now technically possible. We will send an update when
>>> > the RFC and implementation are ready for re-review.
>>> >
>>>
>>> That's great news!
>>>
>>> By the way, I forgot to add that another syntax might also be clearer
>>> when
>>> binding a value to a named parameter, e.g.:
>>>
>>> ```
>>> function f($a, $b, $c, $d, $e) {/*...*/}
>>>
>>> /* We want to bind value 4 to param "d" */
>>>
>>> // with current syntax:
>>> $p =3D f(?, d: 4); /* or f(?, ?, ?, 4) */
>>>
>>> // with another hypothetical syntax:
>>> $p =3D *f(d: 4);
>>> ```
>>>
>>> Anyway, looking forward to your update =3D)
>>>
>>> Thanks,
>>>
>>> --
>>> Guilliam Xavier
>>>
>>
>> Hey Guilliam,
>>
>> adding a special character like * or ? before the function name is
>> not going to work.
>> It might look good for *f() but it has the same issues as casting.
>>
>> You should be able to have with the current version a code like
>> $actionGenerator->getDriveAction()('home', ?)
>> You can't really put the * or ? before the function name here.
>>
>> Maybe having it just before the parenthesis would work.
>>
>> Regards,
>> Alex
>>
>>
>>
>>
> Hey Alex,
>
> I was thinking of a (special) new unary [prefix] operator (e.g. `*` which
> currently only exists as binary) with a higher precedence than `()` (if
> that makes sense), which indeed means that e.g. `*f(1)(2)` would be like
> current `f(1, ?)(2)`, and `f(1)(2, ?)` would require wrapping as
> `*(f(1))(2)`.
> A lower precedence would require wrapping as `(*f)(1)` for the simple cas=
e
> (i.e. most of the time), which moreover would probably be problematic if
> you have both a `function f` and a `const f`.
>
> Just before the affected `(` might also work indeed, but with another
> symbol, as `f(1)*(2)` [and `f*(1)`] already means `f(1) * 2` [and `f *
> 1`].  Maybe `!`, `@` or `~` would be unambiguous at that position?
>
> (For both, there's also the possibility of choosing not a symbol but a
> keyword...)
>
> Alternatively, `f(..., d: 4)` or probably rather `f(d: 4, ...)` would
> arguably still be clearer than the current `f(?, d: 4)`, but still wouldn=
't
> really solve the "weirdness" of `noParam(...)` and `threeParams(1, 2, 3,
> ...)`.
>
> Sorry, I didn't intend to diverge so much.  The gist is that I (too) don'=
t
> like the current "duality" of `?`.
>


Actually, the current form is not very troublesome to me.
In terms of partial function application, it is fine and it serves the
purpose good enough while having a simple form.

The issue is that in recent discussions, also considering that parameter
re-ordering issue is done, it appears that we can use it also for other use
cases like simple pass-through adaptors between two interfaces.
And because of that, I would like to have also a partial closure where the
extra parameters are not passed further. And that is currently not
possible. Whether this feature is considered out-of-scope for partials,
that's for RFC authors to decide.

Cheers,

> Alex

>

--00000000000006d22905c28b1420--