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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
