Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92767
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAEbg-4Y22ORY-A-e-T-54ba+=ifR7u4u+NgJkmqGDhynGAXJYQ@mail.gmail.com>
References: <CAEbg-4aZytKiqG3Y5U-HrBMp2+JuGHu3UTOMLWiiUQn59FtpLw@mail.gmail.com>
	<CA+9eiLvkoTB2xdo4a6AdDnU8fjxOBbog+4FHm-UyBZzWNOQd4Q@mail.gmail.com>
	<CAF+90c8tSa640KrkzMk0kCE8x06m=y007u4zyB9_Zrh7vP3mJg@mail.gmail.com>
	<CAEbg-4ZoLQ_MKPz4b9PoCuLj5rBYBOnSbnF4c2PG4odV=Vv=Rg@mail.gmail.com>
	<CAF+90c-+zdywtuzVvpqxY_ZmrsAH++z5_kHMo9Lg1k_dJfYnMQ@mail.gmail.com>
	<CA+9eiLvVySGcxaB5q4a-tyUaKQE5wnv+asJni+s++BZXO5u+pg@mail.gmail.com>
	<CAESVnVq-JeioKBLwVFx+Ozx1HegtyH6241rgweMh+68yZZoX+w@mail.gmail.com>
	<CA+9eiLvE8bFCdo=2ZJ6anMvHy+UhF-4C+_T_D7oQgkboHC-f=Q@mail.gmail.com>
	<CAEbg-4Y0gzvSCPvboVR0UPv7V0RFLHSCeKdsgKDsjg01OAjpcA@mail.gmail.com>
	<CAPwsocGBLBzBwVeB_xS04jPMyueqbBhR_B7ud=11pNFO6d6+Eg@mail.gmail.com>
	<CAEbg-4Y22ORY-A-e-T-54ba+=ifR7u4u+NgJkmqGDhynGAXJYQ@mail.gmail.com>
Date: Tue, 26 Apr 2016 10:15:28 +0200
Message-ID: <CAF+90c_zAMQi6xJPoZzQwF5KjW3z7biyR+Nz2+_7f0R0KBM_pQ@mail.gmail.com>
To: Alexander Lisachenko <lisachenko.it@gmail.com>
Cc: Leigh <leight@gmail.com>, Sara Golemon <pollita@php.net>, Nikita Popov <nikic@php.net>, 
	PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f43dc63543d05315ee51c
Subject: Re: [PHP-DEV] [RFC][Discussion] Parser extension API
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113f43dc63543d05315ee51c
Content-Type: text/plain; charset=UTF-8

On Tue, Apr 26, 2016 at 9:42 AM, Alexander Lisachenko <
lisachenko.it@gmail.com> wrote:

> Hello, internals!
>
> I'd like to bring this topic to the discussion again, because now we have
> a shiny PHP7 engine and keep moving. PHP grammar becomes more complex and
> internal AST representation isn't available for the userland developers, so
> all static analysis tools suffering from the lack of native AST API for
> that. Only possible way for that is to perform tokenization of source code
> and then manually reconstruct an AST (thanks to the PHP-Parser and Nikita
> for doing this job for us, developers)
>
> Several days ago, Dmitry published a RFC for native attributes, which can
> be a great tool for building more complex stuff on top of this metadata.
> However, all attribute expressions will be stored as an AST nodes, so we
> need an AST API again to analyse, parse or compile AST back into the source
> code for evaling, etc.
>
> It would be nice to push php-ast extension (or similar one) into the core,
> providing an API via static class, for example "Php\Parser".
>

As an update here, I plan to create an RFC for bundling the php-ast
extension (maybe with minor modifications) with php-src. This was planned
for 7.1 anyway, and with the annotations RFC under discussion, this seems
like a good time.

However, I will limit this RFC to the current state of the extension, i.e.
I will not include the ability to inject the AST back into the PHP compiler
-- as already mentioned this is very complicated (due to validation
concerns) and should be left for future scope. Some concerns like pretty
printing (compiling AST back to PHP code) will also be left for userland
(e.g. tpunt has a library for this), as doing this in core (on the exported
AST) is unnecessarily complicated, fragile and not sufficiently flexible
(e.g. with regard to formatting).

I'll try to post an RFC for review this week.

Regards,
Nikita

--001a113f43dc63543d05315ee51c--