Hey folks!
Some people asked me what the advantages of using an AST-based
parsing/compilation process are, so I put together a few quick notes
in an RFC:
https://wiki.php.net/rfc/ast_based_parsing_compilation_process
It would be nice to get a few comments from other core devs on this.
Nikita
-
> Some people asked me what the advantages of using an AST-based
> parsing/compilation process are, so I put together a few quick notes
> in an RFC:
>
> https://wiki.php.net/rfc/ast_based_parsing_compilation_process
>
> It would be nice to get a few comments from other core devs on this.
Pardon
On 04/09/12 21:45, Sean Coates wrote:
Pardon my obviously amateur question, but would you build an AST-based
compiler/parser to generate the same (minus the ones you intend to eliminate)
opcodes to run on the VM in the same way as the current compiler does?
Sure. We're changing the route we go
On Tue, Sep 4, 2012 at 3:57 PM, Nikita Popov wrote:
> Hey folks!
>
> Some people asked me what the advantages of using an AST-based
> parsing/compilation process are, so I put together a few quick notes
> in an RFC:
>
> https://wiki.php.net/rfc/ast_based_parsing_compilation_process
>
> It would be
On 04/09/12 23:00, Adam Jon Richardson wrote:
I''m not a core developer, but I do have some concerns about this type
of approach:
As noted in the RFC, most languages do use an Abstract Syntax Tree
(AST), however, as is also noted in the RFC, PHP opcodes are
regenerated by request, which makes P
On Tue, Sep 4, 2012 at 6:02 PM, Andrew Faulds wrote:
> APC will make things faster, though, you're missing that. And optimisations,
> which an AST would help, would make it even faster.
Respectfully, I didn't miss that, and I alluded to that potential in
my response (did you read all of my respon
On Tue, Sep 4, 2012 at 4:20 PM, Adam Jon Richardson wrote:
>
> However, as Knuth has said, "It is often a mistake to make a priori
> judgments about what parts of a program really critical, since the
> universal experience of programmers who have been using measurement
> tools has been that their
On Tue, Sep 4, 2012 at 8:09 PM, Levi Morrison wrote:
> This is probably why the section in the RFC is so small . . . :)
The section covering the potential for potential optimizations isn't so small :)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.
On Tue, Sep 4, 2012 at 9:17 PM, Adam Jon Richardson wrote:
> On Tue, Sep 4, 2012 at 8:09 PM, Levi Morrison wrote:
>> This is probably why the section in the RFC is so small . . . :)
>
> The section covering the potential for potential optimizations isn't so small
> :)
And, apparently, "potentia
Hi,
On 04/09/12 21:57, Nikita Popov wrote:
Hey folks!
Some people asked me what the advantages of using an AST-based
parsing/compilation process are, so I put together a few quick notes
in an RFC:
https://wiki.php.net/rfc/ast_based_parsing_compilation_process
It would be nice to get a few com
Hi Nikita,
Personally, I don't see any reason to build AST. As you mentioned
yourself, it will be slower and will require more memory. On the other
hand AST itself would allow to perform only very basic optimizations.
Most of them can be easily done on VM opcode level as well.
Also, as it's
Hi Dmitry,
On 06/09/12 07:37, Dmitry Stogov wrote:
Hi Nikita,
Personally, I don't see any reason to build AST. As you mentioned
yourself, it will be slower and will require more memory. On the other
hand AST itself would allow to perform only very basic optimizations.
Most of them can be eas
Hi
> The lexing and parsing processes will not be slower than actual, and the
construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode caching, it will remove a lot of hacks, it
wi
Hi!
>> The lexing and parsing processes will not be slower than actual, and the
> construction of an AST is a new process. Well, as usual, new process
> requires new resources. But if we look further, it will certainly be a nice
> tool to perform better opcode caching, it will remove a lot of hack
On 06/09/12 10:11, Stas Malyshev wrote:
Hi!
The lexing and parsing processes will not be slower than actual, and the
construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode ca
On 09/06/2012 06:37 AM, Dmitry Stogov wrote:
The only real advantage could be an ability to expose AST to PHP scripts,
but only few people may need it.
Everyone working on static analysis tools for PHP code needs access to
the (canonical) AST. While the number of people behind this "everyone"
On 09/06/2012 09:11 AM, Stas Malyshev wrote:
As for third-party tools, I do not see why third-party tools need PHP
to change the parser. If PHP's parser is not good enough for those tools,
they can have their own parser.
Nikita is doing an amazing job with PHP_Parser, which is such a
third-pa
Hi!
> Nikita is doing an amazing job with PHP_Parser, which is such a
> third-party tool. However, it will always lag behind the canonical
> parser. And it will (probably) never match 100% the behavior of the
> canonical parser.
Wait, so the arguments that it will be amazingly easy to imp
On 09/06/2012 10:47 AM, Sebastian Bergmann wrote:
> On 09/06/2012 06:37 AM, Dmitry Stogov wrote:
>> The only real advantage could be an ability to expose AST to PHP scripts,
>> but only few people may need it.
>
> Everyone working on static analysis tools for PHP code needs access to
> the (cano
On Thu, Sep 6, 2012 at 11:10 AM, Stas Malyshev wrote:
> Hi!
>
> > Nikita is doing an amazing job with PHP_Parser, which is such a
> > third-party tool. However, it will always lag behind the canonical
> > parser. And it will (probably) never match 100% the behavior of the
> > canonical par
On 09/06/2012 10:15 AM, Ferenc Kovacs wrote:
I propose putting together and RFC and a PoC ASAP, and then we can talk
about facts instead of opinions and biased views on the topic.
That would be the reasonable thing to do, yes. But that is easy for me
easy to say as I will not be able to help
On Thu, Sep 6, 2012 at 2:53 PM, Sebastian Bergmann wrote:
> On 09/06/2012 10:15 AM, Ferenc Kovacs wrote:
>
>> I propose putting together and RFC and a PoC ASAP, and then we can talk
>> about facts instead of opinions and biased views on the topic.
>>
>
> That would be the reasonable thing to do,
On Thu, 2012-09-06 at 09:47 +0100, Sebastian Bergmann wrote:
> On 09/06/2012 06:37 AM, Dmitry Stogov wrote:
> > The only real advantage could be an ability to expose AST to PHP scripts,
> > but only few people may need it.
>
> Everyone working on static analysis tools for PHP code needs access t
On 09/06/2012 11:52 AM, Ivan Enderlin @ Hoa wrote:
Hi Dmitry,
On 06/09/12 07:37, Dmitry Stogov wrote:
Hi Nikita,
Personally, I don't see any reason to build AST. As you mentioned
yourself, it will be slower and will require more memory. On the other
hand AST itself would allow to perform only
On Thu, Sep 6, 2012 at 11:10 AM, Stas Malyshev wrote:
> And if it's impossible to match behavior of the existing parser - do I
> get it right that the proposed idea is to actually break real code that
> people run now in PHP because it was too hard to parse for people that
> write add-on tools to
25 matches
Mail list logo