Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62856
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5048686E.5080800@sugarcrm.com>
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>
	<5048686E.5080800@sugarcrm.com>
Date: Thu, 6 Sep 2012 11:15:00 +0200
Message-ID: <CAH-PCH4p-4pN6v6=BLqhnjzr6G-iJZ1K1VBM-vqwjudevUxidw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Sebastian Bergmann <sebastian@php.net>
Content-Type: multipart/alternative; boundary=f46d042ef4670aa5b104c904ed72
Subject: Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
From: tyra3l@gmail.com (Ferenc Kovacs)

--f46d042ef4670aa5b104c904ed72
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 6, 2012 at 11:10 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrot=
e:

> 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 stat=
ic
> >   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 th=
e
> >   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.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--f46d042ef4670aa5b104c904ed72--