Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76313
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <CAF+90c-YUMUUQbcYxBPFPm1Q5eoX2=QOPrUMC=EVaxfO2QjKiA@mail.gmail.com>
Date: Sat, 2 Aug 2014 22:27:31 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F310104A-1E82-4E64-8C23-42E9BAE51BA2@ajf.me>
References: <CAF+90c-JHQ4MNLEDP6pZgw6YY37j2dzUK3k26cMWdpbXa1jRGA@mail.gmail.com> <3F1B2834-3939-4F86-86E0-207D2CE469D6@ajf.me> <CAF+90c-YUMUUQbcYxBPFPm1Q5eoX2=QOPrUMC=EVaxfO2QjKiA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree
From: ajf@ajf.me (Andrea Faulds)

Hi!

On 2 Aug 2014, at 21:44, Nikita Popov <nikita.ppv@gmail.com> wrote:

> Why do you think this isn't a good idea? I think it would be a nice =
way to prototype language features before pulling them into PHP. Though =
admittedly I don't think there are many things that could be implemented =
that way.

If people can extend the syntax, they will, and I don=92t like the =
possible consequences of that. I=92m all for overloading, but if people =
start relying on custom syntactical features, it means non-portable and =
confusing to read code. Granted, it might be useful for prototyping, but =
prototyping itself would be easier with an AST, so I=92m not sure it =
matters.

> A native extension has the limitation that it will not be able to =
parse files for newer PHP versions (which, depending on the use case may =
or may not be a problem) and probably won't provide a stable structure =
across versions. At least I think giving BC guarantees on the AST =
structure between minor versions would be way too limiting for us. As =
such I think both a native ext (which provides awesome perf) and =
PHP-Parser (which provides x-compat) have their place ;)

Yeah, I was thinking that you could keep it around for version =
compatibility. You could even make your library pass through to the =
native ext where possible. :)

> Yes, the AST structure is based on the existing work on constant =
scalar expressions, though by now the structure and API deviate a good =
bit from that. It doesn't cause problems for them - constant expressions =
go through a validation that checks that only valid nodes are used and =
adjusts those nodes that have special representation for the constexpr =
case (e.g. constant and class constant access)

Ah, I see.

--
Andrea Faulds
http://ajf.me/