# [RFC] Introduce Abstract Syntax Tree - Thread: https://externals.io/message/76294 - Original archive: https://news-web.php.net/php.internals/76294 - Started by Nikita Popov on 2014-07-31T18:11:38+00:00 - Messages: 36 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/76294.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #76294 — Nikita Popov — 2014-07-31T18:11:38+00:00 URL: https://externals.io/message/76294#76294 Hi internals! I've created a draft RFC and implementation for the introduction of an Abstract Syntax Tree (AST) as an intermediate structure in our compilation process: https://wiki.php.net/rfc/abstract_syntax_tree The RFC outlines why an AST is beneficial, how it impacts performance and memory usage of the compile process and what changes to syntax or behavior it introduces. Furthermore the RFC contains an outline of how the current implementation works and what APIs it provides. This section is just an overview and I hope to extend it in the future. Note: I'm on vacation as of tomorrow and wanted to put this up to discussion beforehand. I won't be able to implement any feedback while I'm away, but can of course answer questions :) Thanks, Nikita --- ## #76295 — Sara Golemon — 2014-07-31T18:19:53+00:00 URL: https://externals.io/message/76294#76295 · In reply to: #76294 > I've created a draft RFC and implementation for the introduction of an > Abstract Syntax Tree (AST) as an intermediate structure in our compilation > process: > > https://wiki.php.net/rfc/abstract_syntax_tree > > The RFC outlines why an AST is beneficial, how it impacts performance and > memory usage of the compile process and what changes to syntax or behavior > it introduces. > > Furthermore the RFC contains an outline of how the current implementation > works and what APIs it provides. This section is just an overview and I > hope to extend it in the future. > +1 all the way, man. --- ## #76296 — Michael Wallner — 2014-07-31T18:27:05+00:00 URL: https://externals.io/message/76294#76296 · In reply to: #76294 > Hi internals! > > I've created a draft RFC and implementation for the introduction of an > Abstract Syntax Tree (AST) as an intermediate structure in our compilation > process: > > https://wiki.php.net/rfc/abstract_syntax_tree > > The RFC outlines why an AST is beneficial, how it impacts performance and > memory usage of the compile process and what changes to syntax or behavior > it introduces. > > Furthermore the RFC contains an outline of how the current implementation > works and what APIs it provides. This section is just an overview and I > hope to extend it in the future. > Sounds great! BTW, wasn't there a related AST GSOC project once? -- Regards, Mike --- ## #76297 — guilhermeblanco@gmail.com — 2014-07-31T18:31:11+00:00 URL: https://externals.io/message/76294#76297 · In reply to: #76296 OMG, so +1 on this! *rolling eyes* We'd be a step away for hookable grammars! \o/ > > > > […] > compilation > > […] > behavior > > […] > > Sounds great! BTW, wasn't there a related AST GSOC project once? > > > -- > Regards, > Mike > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #76298 — Andrea Faulds — 2014-07-31T19:03:14+00:00 URL: https://externals.io/message/76294#76298 · In reply to: #76294 > I've created a draft RFC and implementation for the introduction of an > Abstract Syntax Tree (AST) as an intermediate structure in our compilation > process: Oh man, you got the implementation done? That makes me so happy. ^^ Like Sara, I am very, very much for this. There are so many potential benefits, and the only real downside IMO (memory use and performance at parsing-time) is largely negated by using opcache, a built-in feature of PHP. An AST is really the most obvious and best way to do compilation, IMO, and as it so happens, I’ve used them in the past when implementing a programming language I designed. A benefit I particularly like is we could perhaps add nicer generator expression and list() syntaxes, as you have described. I can’t remember if you implemented the former. If you did, I’d love it if you’d also propose it should ASTs get in, they’re an awesome feature and it is a shame we didn’t get them when we got generators. On another note, while we *could* allow extensions to hook into the AST, I’d stray away from letting them modify it and implement new features. That really doesn’t sound like a good idea at all (I could elaborate on why, but I won’t bother unless someone asks me). Letting them read it would clearly be a good thing though. Side note: Would that obsolete your PHP-Parser userland library once an extension allows reading the AST? If an extension is written, perhaps it should have the same API as your library had. I believe many projects already use it. On an *implementation* note, I assume this is based on the existing constant ASTs, unless you renamed it to something other then zend_ast. Does this cause any problems for them? While I can see the benefits of course, I’d just like to be sure that the validator doesn’t let anything slip through. It’s also nice to see zend_emit_op and _jump, I suspect they’ll make code easier to read (currently I have to scan for the other operands sometimes as they’re not always set together). Again, I really like this. I look forward to its inclusion. Thank you so much! -- Andrea Faulds http://ajf.me/ --- ## #76305 — Sebastian Bergmann — 2014-08-01T06:25:28+00:00 URL: https://externals.io/message/76294#76305 · In reply to: #76294 Am 31.07.2014 um 20:11 schrieb Nikita Popov: > https://wiki.php.net/rfc/abstract_syntax_tree Is it Christmas already? Seriously: +1 from me. Especially because of "The generated AST can be exposed to userland via an extension, for use by static analysers. This should be relatively easy to implement and we might even want to provide this as a bundled extension." Your PHP-Parser is great, Nikita, but having the same functionality built into PHP means that it will be authorative (as it is based on the actual AST that the compiler uses) and faster. --- ## #76306 — Julien Pauli — 2014-08-01T09:21:59+00:00 URL: https://externals.io/message/76294#76306 · In reply to: #76298 > > > > > […] > compilation > > […] > > Oh man, you got the implementation done? That makes me so happy. ^^ > > Like Sara, I am very, very much for this. There are so many potential > benefits, and the only real downside IMO (memory use and performance at > parsing-time) is largely negated by using opcache, a built-in feature of > PHP. An AST is really the most obvious and best way to do compilation, IMO, > and as it so happens, I’ve used them in the past when implementing a > programming language I designed. > > A benefit I particularly like is we could perhaps add nicer generator > expression and list() syntaxes, as you have described. I can’t remember if > you implemented the former. If you did, I’d love it if you’d also propose > it should ASTs get in, they’re an awesome feature and it is a shame we > didn’t get them when we got generators. > > On another note, while we *could* allow extensions to hook into the AST, > I’d stray away from letting them modify it and implement new features. That > really doesn’t sound like a good idea at all (I could elaborate on why, but > I won’t bother unless someone asks me). Letting them read it would clearly > be a good thing though. Side note: Would that obsolete your PHP-Parser > userland library once an extension allows reading the AST? If an extension > is written, perhaps it should have the same API as your library had. I > believe many projects already use it. > > On an *implementation* note, I assume this is based on the existing > constant ASTs, unless you renamed it to something other then zend_ast. Does > this cause any problems for them? While I can see the benefits of course, > I’d just like to be sure that the validator doesn’t let anything slip > through. > > It’s also nice to see zend_emit_op and _jump, I suspect they’ll make code > easier to read (currently I have to scan for the other operands sometimes > as they’re not always set together). > > Again, I really like this. I look forward to its inclusion. Thank you so > much! > > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > > > > That's nice Nik ;-) As I told you on IRC, I'm all in for developping an extension that could play with the AST. I like Andrea's suggestion of publishing to userland an API that looks like PHPParser :-) Julien.P --- ## #76307 — rich gray — 2014-08-01T16:43:54+00:00 URL: https://externals.io/message/76294#76307 · In reply to: #76294 > Hi internals! > > I've created a draft RFC and implementation for the introduction of an > Abstract Syntax Tree (AST) as an intermediate structure in our compilation > process: > > https://wiki.php.net/rfc/abstract_syntax_tree > > The RFC outlines why an AST is beneficial, how it impacts performance and > memory usage of the compile process and what changes to syntax or behavior > it introduces. > > Furthermore the RFC contains an outline of how the current implementation > works and what APIs it provides. This section is just an overview and I > hope to extend it in the future. > > Note: I'm on vacation as of tomorrow and wanted to put this up to > discussion beforehand. I won't be able to implement any feedback while I'm > away, but can of course answer questions :) > > Thanks, > Nikita > I know I am not supposed to comment as just a PHP dev who uses the language day to day for my living -- above is another example of why Nikita is a person who just delivers - for me he completely defused the 64bit vs php-ng stuff a few weeks back with a technical analysis i.e. no political crap - so maybe we need an rfc for a benign dictator for PHP (as Rasmus is too busy I guess) and the community seems pretty fractioned with endless arguments .. anyway I think you'd know who'd get my vote :) -- we all know php-ng and 64bit are essential so get them implemented and the documentation can follow... :) Sorry for any unwelcome noise from user land Rich --- ## #76308 — Andrey Andreev — 2014-08-01T21:04:46+00:00 URL: https://externals.io/message/76294#76308 · In reply to: #76306 Hi, I don't really have anything new to say about this, just couldn't resist another +1. This RFC is an example to follow - well thought and written, detailed, implementation ready in spite of it being a real challenge, non-controversial, and even as a userland developer, I can see the benefits. If we were on 9gag, I'd be throwing up rainbows. Great job! Cheers, Andrey. --- ## #76312 — Nikita Popov — 2014-08-02T20:44:41+00:00 URL: https://externals.io/message/76294#76312 · In reply to: #76298 > On another note, while we *could* allow extensions to hook into the AST, > I’d stray away from letting them modify it and implement new features. That > really doesn’t sound like a good idea at all (I could elaborate on why, but > I won’t bother unless someone asks me). Why do you think this isn't a good idea? I think it would be a nice way to prototype language features before pulling them into PHP. Though admittedly I don't think there are many things that could be implemented that way. > Letting them read it would clearly be a good thing though. Side note: > Would that obsolete your PHP-Parser userland library once an extension > allows reading the AST? If an extension is written, perhaps it should have > the same API as your library had. I believe many projects already use it. > A native extension has the limitation that it will not be able to parse files for newer PHP versions (which, depending on the use case may or may not be a problem) and probably won't provide a stable structure across versions. At least I think giving BC guarantees on the AST structure between minor versions would be way too limiting for us. As such I think both a native ext (which provides awesome perf) and PHP-Parser (which provides x-compat) have their place ;) > On an *implementation* note, I assume this is based on the existing > constant ASTs, unless you renamed it to something other then zend_ast. Does > this cause any problems for them? While I can see the benefits of course, > I’d just like to be sure that the validator doesn’t let anything slip > through. > Yes, the AST structure is based on the existing work on constant scalar expressions, though by now the structure and API deviate a good bit from that. It doesn't cause problems for them - constant expressions go through a validation that checks that only valid nodes are used and adjusts those nodes that have special representation for the constexpr case (e.g. constant and class constant access). Nikita --- ## #76313 — Andrea Faulds — 2014-08-02T21:27:31+00:00 URL: https://externals.io/message/76294#76313 · In reply to: #76312 Hi! > Why do you think this isn't a good idea? I think it would be a nice way to prototype language features before pulling them into PHP. Though admittedly I don't think there are many things that could be implemented that way. If people can extend the syntax, they will, and I don’t like the possible consequences of that. I’m all for overloading, but if people start relying on custom syntactical features, it means non-portable and confusing to read code. Granted, it might be useful for prototyping, but prototyping itself would be easier with an AST, so I’m not sure it matters. > A native extension has the limitation that it will not be able to parse files for newer PHP versions (which, depending on the use case may or may not be a problem) and probably won't provide a stable structure across versions. At least I think giving BC guarantees on the AST structure between minor versions would be way too limiting for us. As such I think both a native ext (which provides awesome perf) and PHP-Parser (which provides x-compat) have their place ;) Yeah, I was thinking that you could keep it around for version compatibility. You could even make your library pass through to the native ext where possible. :) > Yes, the AST structure is based on the existing work on constant scalar expressions, though by now the structure and API deviate a good bit from that. It doesn't cause problems for them - constant expressions go through a validation that checks that only valid nodes are used and adjusts those nodes that have special representation for the constexpr case (e.g. constant and class constant access) Ah, I see. -- Andrea Faulds http://ajf.me/ --- ## #76495 — guilhermeblanco@gmail.com — 2014-08-13T17:18:31+00:00 URL: https://externals.io/message/76294#76495 · In reply to: #76313 When is this planned to go through voting process? > Hi! > > > > > […] > to prototype language features before pulling them into PHP. Though > admittedly I don't think there are many things that could be implemented > that way. > > If people can extend the syntax, they will, and I don’t like the possible > consequences of that. I’m all for overloading, but if people start relying > on custom syntactical features, it means non-portable and confusing to read > code. Granted, it might be useful for prototyping, but prototyping itself > would be easier with an AST, so I’m not sure it matters. > > > […] > files for newer PHP versions (which, depending on the use case may or may > not be a problem) and probably won't provide a stable structure across > versions. At least I think giving BC guarantees on the AST structure > between minor versions would be way too limiting for us. As such I think > both a native ext (which provides awesome perf) and PHP-Parser (which > provides x-compat) have their place ;) > > Yeah, I was thinking that you could keep it around for version > compatibility. You could even make your library pass through to the native > ext where possible. :) > > > […] > expressions, though by now the structure and API deviate a good bit from > that. It doesn't cause problems for them - constant expressions go through > a validation that checks that only valid nodes are used and adjusts those > nodes that have special representation for the constexpr case (e.g. > constant and class constant access) > > Ah, I see. > > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > > > > -- Guilherme Blanco MSN: guilhermeblanco@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada --- ## #76496 — Nikita Popov — 2014-08-13T19:05:13+00:00 URL: https://externals.io/message/76294#76496 · In reply to: #76495 On Wed, Aug 13, 2014 at 7:18 PM, guilhermeblanco@gmail.com < guilhermeblanco@gmail.com> wrote: > When is this planned to go through voting process? > Before voting I'd like to have some opinions on the behavioral differences the proposal introduces. In particular I'd like to know whether we are okay with changing order of evaluation in some places. We document that evaluation order is undefined, we document that it can change without warning between versions and that it is inconsistent within one version. However in the current implementation evaluation is usually left-to-right. The AST implementation introduces some places where evaluation is explicitly right-to-left, and not just incidentally. So basically the question is whether we are committed to things like $a[$i++] = $i++ or $a[$i++][$i++] = $j being undefined behavior, in which case order doesn't matter. If not, I can preserve left-to-right behavior here (CVs notwithstanding of course), but it would come at the cost of a good bit of additional complexity in the implementation (I suspect that I'd have to reintroduce parts of the bp stack to properly shuffle the oplines around). My personal opinion is that things like $a[$i++] = $i++ have zero practical relevance (and also think that anyone using something like this deserves any breakage he gets). I'd rather save some lines of code than maintain any behavior guarantees for that. But some people have contrary opinions on this, so I'm bringing up the point for discussion. Nikita --- ## #76497 — Andrey Andreev — 2014-08-13T19:25:33+00:00 URL: https://externals.io/message/76294#76497 · In reply to: #76496 Hi, I'd personally find it horrible if $foo[$i] = $bar[$i++]; is executed right-to-left, but given that your examples are a bit weird, I'm not sure if mine is affected. Is it? Cheers, Andrey. > > On Wed, Aug 13, 2014 at 7:18 PM, guilhermeblanco@gmail.com < > guilhermeblanco@gmail.com> wrote: > > > […] > > Before voting I'd like to have some opinions on the behavioral differences > the proposal introduces. In particular I'd like to know whether we are okay > with changing order of evaluation in some places. We document that > evaluation order is undefined, we document that it can change without > warning between versions and that it is inconsistent within one version. > However in the current implementation evaluation is usually left-to-right. > The AST implementation introduces some places where evaluation is > explicitly right-to-left, and not just incidentally. > > So basically the question is whether we are committed to things like > $a[$i++] = $i++ or $a[$i++][$i++] = $j being undefined behavior, in which > case order doesn't matter. If not, I can preserve left-to-right behavior > here (CVs notwithstanding of course), but it would come at the cost of a > good bit of additional complexity in the implementation (I suspect that I'd > have to reintroduce parts of the bp stack to properly shuffle the oplines > around). > > My personal opinion is that things like $a[$i++] = $i++ have zero practical > relevance (and also think that anyone using something like this deserves > any breakage he gets). I'd rather save some lines of code than maintain any > behavior guarantees for that. But some people have contrary opinions on > this, so I'm bringing up the point for discussion. > > Nikita --- ## #76508 — Chris Wright — 2014-08-14T09:25:11+00:00 URL: https://externals.io/message/76294#76508 · In reply to: #76496 > On Wed, Aug 13, 2014 at 7:18 PM, guilhermeblanco@gmail.com < > guilhermeblanco@gmail.com> wrote: > > > […] > > Before voting I'd like to have some opinions on the behavioral differences > the proposal introduces. In particular I'd like to know whether we are okay > with changing order of evaluation in some places. We document that > evaluation order is undefined, we document that it can change without > warning between versions and that it is inconsistent within one version. > However in the current implementation evaluation is usually left-to-right. > The AST implementation introduces some places where evaluation is > explicitly right-to-left, and not just incidentally. > > So basically the question is whether we are committed to things like > $a[$i++] = $i++ or $a[$i++][$i++] = $j being undefined behavior, in which > case order doesn't matter. If not, I can preserve left-to-right behavior > here (CVs notwithstanding of course), but it would come at the cost of a > good bit of additional complexity in the implementation (I suspect that I'd > have to reintroduce parts of the bp stack to properly shuffle the oplines > around). > > My personal opinion is that things like $a[$i++] = $i++ have zero practical > relevance (and also think that anyone using something like this deserves > any breakage he gets). I'd rather save some lines of code than maintain any > behavior guarantees for that. But some people have contrary opinions on > this, so I'm bringing up the point for discussion. +1. It's documented as undefined behaviour, doing it in the first place is highly non-obvious to the reader with a clear ambiguity, it's fine by me to break from the current behaviour. PHP is not and should not be designed around people who spend their days playing code golf and/or optimising away one opcode at a time. --- ## #76509 — Alain Williams — 2014-08-14T09:33:38+00:00 URL: https://externals.io/message/76294#76509 · In reply to: #76508 > > […] > > +1. It's documented as undefined behaviour, doing it in the first > place is highly non-obvious to the reader with a clear ambiguity, it's > fine by me to break from the current behaviour. +1 It is OK to define some things as undefined and have them break between releases - even minor releases. I always teach it as undefined - as it is in most programming languages. Likewise, if the next 2 characters on input are 'a' then 'b' what gets assigned could either be 'ab' or 'ba': $TwoChars = fgetc($in) . fgetc($in); Some code is just broken. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include > > > […] > > +1 > > It is OK to define some things as undefined and have them break between releases - > even minor releases. I always teach it as undefined - as it is in most > programming languages. > > Likewise, if the next 2 characters on input are 'a' then 'b' what gets assigned > could either be 'ab' or 'ba': > > $TwoChars = fgetc($in) . fgetc($in); > > Some code is just broken. Wat? No. This is totally different to two in/decrements on one line. This has to be executed in order. Cheers, Mike --- ## #76514 — Christoph Becker — 2014-08-14T11:30:27+00:00 URL: https://externals.io/message/76294#76514 · In reply to: #76513 Michael Wallner wrote: > > > > […] > > Wat? No. This is totally different to two in/decrements on one line. This has to be executed in order. The current specification draft says[1]: | Unless stated explicitly in this specification, the order in which | the operands in an expression are evaluated relative to each other is | unspecified. | [...] | Finally, in the full expression f() + g() * h(), the order in which | the three functions are called, is unspecified). [1] -- Christoph M. Becker --- ## #76535 — Michael Wallner — 2014-08-15T07:28:15+00:00 URL: https://externals.io/message/76294#76535 · In reply to: #76514 > Michael Wallner wrote: > > > […] Ignore that. > > The current specification draft says[1]: > > | Unless stated explicitly in this specification, the order in which > | the operands in an expression are evaluated relative to each other is > | unspecified. > | [...] > | Finally, in the full expression f() + g() * h(), the order in which > | the three functions are called, is unspecified). > > [1] > > You're right, it's documented, too; in the operator section not in the expression section, though: ---8<--- PHP does not (in the general case) specify in which order an expression is evaluated and code that assumes a specific order of evaluation should be avoided, because the behavior can change between versions of PHP or depending on the surrounding code. --->8--- http://php.net/manual/en/language.operators.precedence.php -- Regards, Mike --- ## #76558 — Nikita Popov — 2014-08-15T15:36:21+00:00 URL: https://externals.io/message/76294#76558 · In reply to: #76497 > Hi, > > I'd personally find it horrible if $foo[$i] = $bar[$i++]; is executed > right-to-left, but given that your examples are a bit weird, I'm not sure > if mine is affected. Is it? > > Cheers, > Andrey. > I've decided that I'd rather avoid this particular discussion and just implemented LTR evaluation. Nikita --- ## #76560 — Christoph Becker — 2014-08-15T15:58:24+00:00 URL: https://externals.io/message/76294#76560 · In reply to: #76497 Andrey Andreev: > I'd personally find it horrible if $foo[$i] = $bar[$i++]; is executed > right-to-left, but given that your examples are a bit weird, I'm not sure > if mine is affected. Is it? Isn't that evaluated from right to left already since PHP 5.1.0? See . -- Christoph M. Becker --- ## #76561 — Nikita Popov — 2014-08-15T16:11:28+00:00 URL: https://externals.io/message/76294#76561 · In reply to: #76560 > Andrey Andreev: > > > […] > > Isn't that evaluated from right to left already since PHP 5.1.0? See > . > Yes, anything containing simple variables (like $i) will often deviate from the usual evaluation order due to the CV optimization. I don't touch that. What I've changed now is that ${a()}[b()] = c() will continue to call a, b, c, rather than calling c, b, a (which was what the AST implementation initially did). I honestly don't think that it matters, but I figured that it's best to stick with the more "logical" behavior as long as it's not too much trouble :) Nikita --- ## #76562 — Andrey Andreev — 2014-08-15T16:29:23+00:00 URL: https://externals.io/message/76294#76562 · In reply to: #76560 > Andrey Andreev: > > > […] > > Isn't that evaluated from right to left already since PHP 5.1.0? See > . > > -- > Christoph M. Becker Huh, I never suspected that. I've written a lot of code that relies on increments in one-liners, possibly not for assignment though. I better go and do some greps for this ... Cheers, Andrey. --- ## #76569 — Christoph Becker — 2014-08-15T20:09:54+00:00 URL: https://externals.io/message/76294#76569 · In reply to: #76561 Nikita Popov wrote: > Yes, anything containing simple variables (like $i) will often deviate from > the usual evaluation order due to the CV optimization. I don't touch that. > What I've changed now is that ${a()}[b()] = c() will continue to call a, b, > c, rather than calling c, b, a (which was what the AST implementation > initially did). I honestly don't think that it matters, but I figured that > it's best to stick with the more "logical" behavior as long as it's not too > much trouble :) Thanks for the explanation. :) Anyway, I try to avoid relying on any particular evaluation order between sequence points. -- Christoph M. Becker --- ## #76629 — Dmitry Stogov — 2014-08-18T07:32:08+00:00 URL: https://externals.io/message/76294#76629 · In reply to: #76294 Hi Nikita, I think RFC misses few important notes about behavior changes: 1) The behavior of $a->$b[$c] is changed. PHP apps that used such syntax have to be changed into $a->{$b[$c]}. 2) The evaluation order of left and right parts of assignment is changed. $a[$i++] = $a[$i++]; It wasn't guaranteed before, but it may break some code anyway. 3) $a=[1,2]; list($a,$b) = $a; won't work in the same way as before 4) Usage of undefined constants now leads to fatal errors? (see Zend/tests/use_const/no_global_fallback.php) 5) The patch also enables expressions on constant arrays e.g. isset(arra(1,2,3)[$x]); Personally, I would prefer to separate syntax and behavior changes from the AST patch itself or at least don't miss such changes, because they must be very significant from users point of view. Also some implementation related notes: - Changes to Zend/tests/bug43450.phpt are unrelated to AST. It's just a bad test that may be fixed separately. - I didn't get why you deleted Zend/tests/errmsg_014.php - ZEND_INIT_FCALL_BY_NAME handler shouldn't check if constant operand is a string. Compiler must not provide non-string constant operand. (All the changes to ZEND_INIT_FCALL_BY_NAME need to be verified more careful) - The same in ext/opcache/Optimizer/optimize_func_calls.c, but it's not critical here. - I think you don't need IS_CONST operand for ZEND_ISSET_ISEMPTY_PROP_OBJ handler. - Can OPcahce always keep AST in shared memory and don't copy it into process memory on each request? (ext/opcache/zend_accelerator_util_funcs.c) Thanks. Dmitry. > Hi internals! > > I've created a draft RFC and implementation for the introduction of an > Abstract Syntax Tree (AST) as an intermediate structure in our compilation > process: > > https://wiki.php.net/rfc/abstract_syntax_tree > > The RFC outlines why an AST is beneficial, how it impacts performance and > memory usage of the compile process and what changes to syntax or behavior > it introduces. > > Furthermore the RFC contains an outline of how the current implementation > works and what APIs it provides. This section is just an overview and I > hope to extend it in the future. > > Note: I'm on vacation as of tomorrow and wanted to put this up to > discussion beforehand. I won't be able to implement any feedback while I'm > away, but can of course answer questions :) > > Thanks, > Nikita --- Next page: https://externals.io/message/76294.md?page=2