Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119707
MIME-Version: 1.0
References: <CAM0CcxhpMr_SstLCgcMfESTo4_H6yAPuBZb6B08KjbnKS97VfA@mail.gmail.com>
 <9975B833-EE24-4ED7-B28E-841B92988BA0@cschneid.com> <CAPzBOBPP8xy6S4nv2i8t1bgPj0hvFw4seBQ31QFSpA9aeAPyAA@mail.gmail.com>
 <CALKiJKoW0obHeG+53Yai25BHVDiscW6X7pn-uH+OLBDvvDQJ8Q@mail.gmail.com>
 <CAPzBOBMVnACDUrH=jCKPSNonzcv3Zm4J5yr5h1vVXHVOi872mA@mail.gmail.com>
 <1A2CE63B-ECCA-403D-83AC-B1E26279323C@gmail.com> <9a2140b4-97bb-4a9c-90c5-809274c83f75@app.fastmail.com>
 <88c4a63c-859b-94d5-e314-3399fb2c3fb0@gmail.com> <AM8P250MB017093F4BFE7C9E7B63AEF9CE2BE9@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <CALKiJKqf5WqYw8qS=3-OQW_s02_7THr6FMP99USJfnNFpwvFDQ@mail.gmail.com>
 <CAPzBOBNGRiT6Y5grn7FHSu9xEsqqdHEeMW1dvuQCV30sf5wE2w@mail.gmail.com> <1a4d4434-7318-4831-9fc0-8b48a6400a62@app.fastmail.com>
In-Reply-To: <1a4d4434-7318-4831-9fc0-8b48a6400a62@app.fastmail.com>
Date: Wed, 15 Mar 2023 11:17:04 +0100
Message-ID: <CAPzBOBMotNtnZU0HmMXi_6+HWcLJH1kHkhniyzBxe4foEif=+A@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] First-class callable partial application
From: landers.robert@gmail.com (Robert Landers)

On Tue, Mar 14, 2023 at 5:58=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com> wrote:
>
> On Tue, Mar 14, 2023, at 8:50 AM, Robert Landers wrote:
> > On Tue, Mar 14, 2023 at 1:57=E2=80=AFPM Rowan Tommins <rowan.collins@gm=
ail.com> wrote:
> >>
> >> On Tue, 14 Mar 2023 at 10:39, Bob Weinand <bobwei9@hotmail.com> wrote:
> >>
> >> > Hey Rowan,
> >> >
> >> > do we actually need *positional* partial application, after a ... to=
ken?
> >> >
> >> > Would it not be enough, to simply forbid positional arguments after =
a ...
> >> > and just allow named arguments? These already have well defined posi=
tion
> >> > independent semantics.
> >> >
> >> > There may be some desire for a single argument placeholder later on,=
 but
> >> > this can be introduced later, separately.
> >> >
> >>
> >>
> >> Yes, named parameters would certainly be better than left-to-right onl=
y.
> >> It's definitely less elegant, though, and given that PFA is largely
> >> short-hand for a short closure anyway, I think conciseness is quite an
> >> important aim.
> >>
> >> To take a couple of the above examples, and compare existing short clo=
sure,
> >> fully positional PFA, and named-after-placeholder PFA:
> >>
> >> $isLogger =3D fn($object) =3D> is_subclass_of($object, LoggerInterface=
::class,
> >> false);
> >> $isLogger =3D is_subclass_of(?, LoggerInterface::class, false);
> >> $isLogger =3D is_subclass_of(..., class: LoggerInterface::class,
> >> allow_string: false);
> >>
> >> $priceFormatter =3D fn(float $num) =3D> number_format($num, 2, ',', '.=
');
> >> $priceFormatter =3D number_format(?, 2, ',', '.');
> >> $priceFormatter =3D number_format(..., decimals: 2, decimal_separator:=
 ',',
> >> thousands_separator: '.');
> >>
> >> Arguably the named param version is more explicit, but in some cases i=
t's
> >> significantly longer than manually defining a closure, whereas fully
> >> positional PFA is always shorter.
> >>
> >> Regards,
> >> --
> >> Rowan Tommins
> >> [IMSoP]
> >
> > Something I was partial to (pun slightly intended), when thinking
> > about it last summer was to put named parameters with dots following,
> > like this:
> >
> > $isLogger =3D is_subclass_of(object_or_class..., LoggerInterface::class=
, false);
> > // or, since this is a beginning/end partial, this is the same:
> > $isLogger =3D is_subclass_of(..., LoggerInterface::class, false);
> >
> > $isLogger(object_or_class: $myClass);
> > // or
> > $isLogger($myClass);
> >
> > $priceFormatter =3D number_format(num..., 2, ',', '.');
> >
> > At least, that was what I was going to propose, according to my notes.
> > Looking at it 8 months later, I still kinda like it.
>
> For reference, in the original RFC we had the following rules:
>
> ```
> This RFC introduces two place holder symbols:
>
>     The argument place holder ? means that exactly one argument is expect=
ed at this position.
>     The variadic place holder ... means that zero or more arguments may b=
e supplied at this position.
>
> The following rules apply to partial application:
>
>     ... may only occur zero or one time
>     ... may only be followed by named arguments
>     named arguments must come after all place holders
>     named placeholders are not supported
> ```
>
> The reason for that was, I believe, because it was too complicated figure=
 out the signature of the resulting closure if named placeholders were allo=
wed after the `...` .  Optional arguments also got weird, IIRC.  We went ar=
ound *a lot* on the details here before settling on the syntax we did.
>
> I agree that requiring all partials to used named args would be a big ste=
p down for usability.
>
> But again, none of this addresses the root issue that doomed the previous=
 RFC: Any syntax that involves a runtime determination of "is this a functi=
on call or a partial application?" is going to involve some really tricky d=
ancing along the critical path of all function calls.  Even though Joe's im=
plementation had no significant performance impact (AFAIR), it still made t=
he code more complex and potentially harder to optimize in the future.
>
> So the only ways forward would be:
>
> 1) Find another approach in the implementation that doesn't have that pro=
blem, which may then changes to the proposed syntax and possibility capabil=
ities.  (I had suggested some prefix on the call to indicate that it's a pa=
rtial and not a call, like %foo(1, ?, 3, ...) or something.)
> 2) The voter base shifts and/or changes its mind and decides that the ext=
ra complexity is worth it.
>
> Redoing the syntax bikeshedding from 3 years ago (dear god, it's been 3 y=
ears?) before one of those two is answered is not productive.  New engine a=
pproach first, then syntax based on what that approach allows.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Hey Larry,

> Redoing the syntax bikeshedding from 3 years ago (dear god, it's been 3 y=
ears?) before one of those two is answered is not productive.  New engine a=
pproach first, then syntax based on what that approach allows.

This is why my approach was one of syntax sugar. Sure, it would make
the call stack weird during exceptions, but all-in-all, not much
changes from an engine standpoint. Most of the changes were to the
grammar IIRC. I'll hop on my old computer this weekend and submit a PR
to make the discussion easier.