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
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
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,
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
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
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
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 (canonical)
On Thu, Sep 6, 2012 at 11:10 AM, Stas Malyshev smalys...@sugarcrm.comwrote:
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
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 sebast...@php.netwrote:
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
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 to
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 smalys...@sugarcrm.com 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
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
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
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 my
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 nikita@gmail.com 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
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
On Tue, Sep 4, 2012 at 6:02 PM, Andrew Faulds a...@ajf.me 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
On Tue, Sep 4, 2012 at 4:20 PM, Adam Jon Richardson adamj...@gmail.com 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
On Tue, Sep 4, 2012 at 8:09 PM, Levi Morrison morrison.l...@gmail.com 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,
On Tue, Sep 4, 2012 at 9:17 PM, Adam Jon Richardson adamj...@gmail.com wrote:
On Tue, Sep 4, 2012 at 8:09 PM, Levi Morrison morrison.l...@gmail.com wrote:
This is probably why the section in the RFC is so small . . . :)
The section covering the potential for potential optimizations isn't so
24 matches
Mail list logo
