Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115225
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>
 <CAAKU0ukubWyC==TAzcVtCwWwR4PmAadc3k04tAyO42rwc9_3rg@mail.gmail.com>
In-Reply-To: <CAAKU0ukubWyC==TAzcVtCwWwR4PmAadc3k04tAyO42rwc9_3rg@mail.gmail.com>
Date: Wed, 30 Jun 2021 10:17:54 +0200
Message-ID: <CAC5V6gjzDVrNbGF1OiORL5xHt8KXjXXpb2QqAj96PBZ6RDDmeQ@mail.gmail.com>
To: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b27ffa05c5f75c6e"
Subject: Re: [PHP-DEV] [Vote] Partial Function Application
From: guilliam.xavier@gmail.com (Guilliam Xavier)

--000000000000b27ffa05c5f75c6e
Content-Type: text/plain; charset="UTF-8"

On Tue, Jun 29, 2021 at 10:32 PM Levi Morrison via internals <
internals@lists.php.net> wrote:

> On Tue, Jun 29, 2021 at 12:05 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
> >
> > 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.com>
> > > > wrote:
> > > >
> > > > > [...]  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
> interacting
> > > > > with the engine in a lot of different places.  [...]
> > > >
> > > > Are you saying that the implementation complexity is mainly due to
> chosing
> > > > a syntax that looks like a function call?  [...]
> > >
> > > 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
> send, of course).  Quoting Joe:
> >
> > "the engine expects certain things to happen, and is designed and then
> optimized around those assumptions ... for example, a stream of INIT, SEND,
> 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
> the complexity comes from.  Which suggests that an approach that works
> using 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 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
> partials either way.)  And I've been told that creating closures in the AST
> compiler is Hard(tm)...
>
> 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.
>

Thanks for clarifications.
IIUC, whatever the syntax, any PFA implementation will need either to hook
into the function call process (current approach) or to create a closure
"from scratch" (which may be actually more complex);
and some degree of [implementation] complexity is conceptually inherent
anyway.
(FCC doesn't need to bind values so might have other options? maybe not...)


> 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.
>

-- 
Guilliam Xavier

--000000000000b27ffa05c5f75c6e--