2021-06-30 19:10 GMT+02:00, Larry Garfield <la...@garfieldtech.com>: > On Wed, Jun 30, 2021, at 8:59 AM, Olle Härstedt wrote: > >> > 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 >> >> >> Wrapping stuff in lambdas is otherwise the obvious solution, no? Make >> `strlen(?)` evaluate to `fn ($x) => strlen($x)`. Does it depend on the >> level of look-ahead in the compiler why it's so hard? Didn't work much >> with scripting language internals. >> >> Olle > > The tricky part is that conversion has to happen entirely at runtime, > because we need the type information from the function being partialed, and > at that point creating an actual closure is, apparently, rather hard. It > cannot be done up at the AST level where it would be conceptually much > easier. > > We've been discussing this for the past several days in chat, and the basic > conclusion is that the PHP engine does not offer any easy way to do this. > It's one hard-and-messy approach or another hard-and-messy approach. So far > no one has figured out a not hard-and-messy way to make it work, regardless > of performance. > > --Larry Garfield
Alright, alright. Guess I have to learn a bit more about the different passes inside the compiler. :) Thanks. Olle -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php