Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115221
MIME-Version: 1.0
References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
 <CAC5V6ghFFjoP_JgUcJ14sFJ0DY-Q4z7qt40j9T5w0C3GHNsCrw@mail.gmail.com>
 <c16544c0-185a-43f9-853a-9941a018abe7@www.fastmail.com> <9f0c9565-22e1-4d94-bef5-cfc44ce02dc5@www.fastmail.com>
In-Reply-To: <9f0c9565-22e1-4d94-bef5-cfc44ce02dc5@www.fastmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Tue, 29 Jun 2021 14:31:41 -0600
Message-ID: <CAAKU0ukubWyC==TAzcVtCwWwR4PmAadc3k04tAyO42rwc9_3rg@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] [Vote] Partial Function Application
From: internals@lists.php.net ("Levi Morrison via internals")

On Tue, Jun 29, 2021 at 12:05 PM Larry Garfield <larry@garfieldtech.com> wr=
ote:
>
> On Tue, Jun 29, 2021, at 1:00 PM, Larry Garfield wrote:
> > On Tue, Jun 29, 2021, at 12:30 PM, Guilliam Xavier wrote:
> > > (Extracted from the "Pipe Operator, take 2" thread)
> > >
> > > On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield <larry@garfieldtech.c=
om>
> > > wrote:
> > >
> > > > On Mon, Jun 28, 2021, at 5:30 PM, Olle H=C3=A4rstedt wrote:
> > > >
> > > > > Would a slimmed down version have more support? How about removin=
g the
> > > > > variadic operator, and let the user manually add the lambda for t=
hose
> > > > > cases?
> > > >
> > > > I talked with Joe about this, and the answer is no.  Most of the
> > > > complexity comes from the initial "this is a function call, oops no=
, it's a
> > > > partial call so we switch to doing that instead", which ends up int=
eracting
> > > > with the engine in a lot of different places.
> > > >
> > >
> > > Are you saying that the implementation complexity is mainly due to ch=
osing
> > > a syntax that looks like a function call?
> > > If yes, is it also the case for the "First-class callable syntax" RFC=
?
> > > And does it mean that a different syntax (e.g. with a prefix operator=
)
> > > would result in a simpler implementation?
> >
> > From what I understand from Joe, most of the complexity comes from
> > producing something that isn't a closure but shares the same interface
> > as a closure (at least that's what it would be in PHP terms), which
> > then requires lots of special handling throughout the engine.  I don't
> > fully understand it all myself, TBH.
> >
> > I've been pondering if a completely different approach with a prefix
> > symbol would be able to be less complex, and the simple answer is I
> > have absolutely no idea.  But we are running low on symbols...
>
> Ah, I found the technical details that Joe gave me (right after I hit sen=
d, of course).  Quoting Joe:
>
> "the engine expects certain things to happen, and is designed and then op=
timized around those assumptions ... for example, a stream of INIT, SEND, D=
O_FCALL is not meant to be interrupted, the first fundamental change you ha=
ve to make is making the engine aware that stream of INIT, SEND, + are not =
always followed by DO_FCALL "
>
> So yes, it sounds like hooking into the function call process is where th=
e complexity comes from.  Which suggests that an approach that works using =
a different syntax that desugars to a closure would avoid that issue, but t=
hen we need a syntax that wouldn't be ambiguous, and that's getting harder =
and harder to find.  (Nikita's first-class-callables RFC notes some of the =
issues with available symbols, and they're essentially the same for partial=
s either way.)  And I've been told that creating closures in the AST compil=
er is Hard(tm)...
>
> --Larry Garfield

Based on what you said, the syntax isn't really the issue. Rather, the
issue is assumptions about how function calls work at the opcode
level. Any implementation of only _partially_ doing a function call
will have to deal with such things in some form. To a degree this is
inherent complexity.

Maybe separate opcodes for every piece of the call would be better in
that optimizers, etc, won't have expectations around the new opcodes
and we don't change assumptions about the existing opcodes? I doubt
that it would be much simpler, but I am curious to know.