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

Reply via email to