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: > > > > > > > On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote: > > > > > > > > > Would a slimmed down version have more support? How about removing 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 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? > > > 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 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)... > > --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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
