Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62840
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.131 as permitted sender)
Message-ID: <5047D4A6.9030003@sugarcrm.com>
Date: Wed, 05 Sep 2012 15:39:34 -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: "Morgan L. Owens" <packrat@nznet.gen.nz>
CC: PHP internals <internals@lists.php.net>
References: <CAF+90c-+Hgcv5B4+eGDS+jEj6oNoyefBWO-M=kvThaVdckz62g@mail.gmail.com> <50474A30.1090802@nznet.gen.nz>
In-Reply-To: <50474A30.1090802@nznet.gen.nz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Moving to an AST-based parsing/compilation process
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> To date, I've been basing work, which exposes syntactic structure, on 
> phc's maketea grammar (Phalanger's is more up to date, but also more 
> complicated what with its provenance and the Linq and generics and all), 
> but it's reverse-engineered and certainly wrong (oh, that reminds 
> me...); the existing grammar is unsuitable because no-one wants to see 
> _that_.

Well, now if you start to implement yet another AST grammar, it would be
"wrong" too, at least for substantial time until the kinks are worked
out - just because it's different approach which probably would work
differently in some corner cases.
So what we're getting on the plus side is more academically nice parser
with potential optimizations, of which nobody knows if they'd have any
real effect and all indications point to the possibility they won't, and
we have some benefits for third parties doing some (unknown to us) work
on PHP.
On the minus side we have major disruption of the code base, virtually
certain BC problems and stability problems, slower compiler and no real
benefit for average PHP user.

I'm not sure this equation has the positives outweigh the negatives.
It'd be nice to support third-part work but I'd propose to start with
writing the actual parser (e.g. as an extension or third-party library)
and see if we can make it as fast and 100% compliant and if it turns out
good then we could talk about replacing current parser with it. In the
meantime you could also use it as base for your work too.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227