Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62854
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender)
Message-ID: <5048686E.5080800@sugarcrm.com>
Date: Thu, 06 Sep 2012 02:10:06 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
CC: Sebastian Bergmann <sebastian@php.net>
References: <CAF+90c-+Hgcv5B4+eGDS+jEj6oNoyefBWO-M=kvThaVdckz62g@mail.gmail.com> <504836A3.20904@zend.com>	<50485647.1060102@hoa-project.net> <CAPwsocGPS7JOxn_Lwx4VZziYrse51aMji3JYx_Aj_Y5EVe4v0w@mail.gmail.com> <50485AA6.4090803@sugarcrm.com> <50486410.4010407@php.net>
In-Reply-To: <50486410.4010407@php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
From: smalyshev@sugarcrm.com (Stas Malyshev)

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