Re: Moving to an AST-based parsing/compilation process

On Thu, Sep 6, 2012 at 11:10 AM, Stas Malyshev <smalyshev@sugarcrm.com>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 parser. > > Wait, so the arguments that it will be amazingly easy to implement new > features in this parser - which should solve the problem of the lag - by > the time the old and clunky parser is released certainly it is possible > to do the same with new, much less complex and much easier to work with > parser? - so these arguments weren't true? Or am I missing some > important reason why parser that is much less complex and easier to add > things to can't do the same old one can do? > > 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 PHP? Somehow it does not sound like a good idea. > If we have doubt that we can match the existing PHP behavior then the > idea of changing parser becomes even less appealing, because for 99% of > PHP users it would be pure downside without upsides. The users don't > care if the parser is complex, they care if their code runs. > > > This is why, from my perspective of someone who is interested in static > > analysis and quality assurance, I think that it would be a tremendous > > boost for the PHP platform if we had a state-of-the-art parser for the > > reference implementation of our programming language. > > I think that the benefit of it for regular PHP user is unclear (and > would not be clear until the real benefit of such parser - such as > promised optimizations, etc. - is demonstrated) but the harm from > breaking of the existing code is obvious. What would happen is that > people would just avoid running such PHP version - and what use then > would be to have excellent tools for PHP that people don't use because > it can't run their code? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > 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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu