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 <la...@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 < > la...@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
