Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115219
User-Agent: Cyrus-JMAP/3.5.0-alpha0-530-gd0c265785f-fm-20210616.002-gd0c26578
Mime-Version: 1.0
Message-ID: <9f0c9565-22e1-4d94-bef5-cfc44ce02dc5@www.fastmail.com>
In-Reply-To: <c16544c0-185a-43f9-853a-9941a018abe7@www.fastmail.com>
References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
 <CAC5V6ghFFjoP_JgUcJ14sFJ0DY-Q4z7qt40j9T5w0C3GHNsCrw@mail.gmail.com>
 <c16544c0-185a-43f9-853a-9941a018abe7@www.fastmail.com>
Date: Tue, 29 Jun 2021 13:05:03 -0500
To: "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: larry@garfieldtech.com ("Larry Garfield")

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)
> >=20
> > On Tue, Jun 29, 2021 at 12:54 AM Larry Garfield <larry@garfieldtech.=
com>
> > wrote:
> >=20
> > > On Mon, Jun 28, 2021, at 5:30 PM, Olle H=C3=A4rstedt wrote:
> > >
> > > > Would a slimmed down version have more support? How about removi=
ng the
> > > > variadic operator, and let the user manually add the lambda for =
those
> > > > 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 n=
o, it's a
> > > partial call so we switch to doing that instead", which ends up in=
teracting
> > > with the engine in a lot of different places.
> > >
> >=20
> > Are you saying that the implementation complexity is mainly due to c=
hosing
> > a syntax that looks like a function call?
> > If yes, is it also the case for the "First-class callable syntax" RF=
C?
> > And does it mean that a different syntax (e.g. with a prefix operato=
r)
> > would result in a simpler implementation?
>=20
> From what I understand from Joe, most of the complexity comes from=20
> producing something that isn't a closure but shares the same interface=
=20
> as a closure (at least that's what it would be in PHP terms), which=20=

> then requires lots of special handling throughout the engine.  I don't=
=20
> fully understand it all myself, TBH.
>=20
> I've been pondering if a completely different approach with a prefix=20=

> symbol would be able to be less complex, and the simple answer is I=20=

> 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 se=
nd, of course).  Quoting Joe:

"the engine expects certain things to happen, and is designed and then o=
ptimized around those assumptions ... for example, a stream of INIT, SEN=
D, DO_FCALL is not meant to be interrupted, the first fundamental change=
 you have 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 t=
he complexity comes from.  Which suggests that an approach that works us=
ing a different syntax that desugars to a closure would avoid that issue=
, but then we need a syntax that wouldn't be ambiguous, and that's getti=
ng 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 partials either way.)  And I've been told that creating closure=
s in the AST compiler is Hard(tm)...

--Larry Garfield