Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76298
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 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-JHQ4MNLEDP6pZgw6YY37j2dzUK3k26cMWdpbXa1jRGA@mail.gmail.com>
Date: Thu, 31 Jul 2014 20:03:14 +0100
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3F1B2834-3939-4F86-86E0-207D2CE469D6@ajf.me>
References: <CAF+90c-JHQ4MNLEDP6pZgw6YY37j2dzUK3k26cMWdpbXa1jRGA@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)


On 31 Jul 2014, at 19:11, Nikita Popov <nikita.ppv@gmail.com> wrote:

> I've created a draft RFC and implementation for the introduction of an
> Abstract Syntax Tree (AST) as an intermediate structure in our =
compilation
> process:

Oh man, you got the implementation done? That makes me so happy. ^^

Like Sara, I am very, very much for this. There are so many potential =
benefits, and the only real downside IMO (memory use and performance at =
parsing-time) is largely negated by using opcache, a built-in feature of =
PHP. An AST is really the most obvious and best way to do compilation, =
IMO, and as it so happens, I=92ve used them in the past when =
implementing a programming language I designed.

A benefit I particularly like is we could perhaps add nicer generator =
expression and list() syntaxes, as you have described. I can=92t =
remember if you implemented the former. If you did, I=92d love it if =
you=92d also propose it should ASTs get in, they=92re an awesome feature =
and it is a shame we didn=92t get them when we got generators.

On another note, while we *could* allow extensions to hook into the AST, =
I=92d stray away from letting them modify it and implement new features. =
That really doesn=92t sound like a good idea at all (I could elaborate =
on why, but I won=92t bother unless someone asks me). Letting them read =
it would clearly be a good thing though. Side note: Would that obsolete =
your PHP-Parser userland library once an extension allows reading the =
AST? If an extension is written, perhaps it should have the same API as =
your library had. I believe many projects already use it.

On an *implementation* note, I assume this is based on the existing =
constant ASTs, unless you renamed it to something other then zend_ast. =
Does this cause any problems for them? While I can see the benefits of =
course, I=92d just like to be sure that the validator doesn=92t let =
anything slip through.

It=92s also nice to see zend_emit_op and _jump, I suspect they=92ll make =
code easier to read (currently I have to scan for the other operands =
sometimes as they=92re not always set together).

Again, I really like this. I look forward to its inclusion. Thank you so =
much!

--
Andrea Faulds
http://ajf.me/