Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76306
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.174 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <3F1B2834-3939-4F86-86E0-207D2CE469D6@ajf.me>
References: <CAF+90c-JHQ4MNLEDP6pZgw6YY37j2dzUK3k26cMWdpbXa1jRGA@mail.gmail.com>
 <3F1B2834-3939-4F86-86E0-207D2CE469D6@ajf.me>
Date: Fri, 1 Aug 2014 11:21:59 +0200
Message-ID: <CAMUwpuROYmBfdr17rONTUr7GZus7CG7J47D8V2ehXbaNJkvavA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf302ef9f6440e0604ff8deeb6
Subject: Re: [PHP-DEV] [RFC] Introduce Abstract Syntax Tree
From: jpauli@php.net (Julien Pauli)

--20cf302ef9f6440e0604ff8deeb6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 31, 2014 at 9:03 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
> 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, IM=
O,
> and as it so happens, I=E2=80=99ve used them in the past when implementin=
g 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=E2=80=99t re=
member if
> you implemented the former. If you did, I=E2=80=99d love it if you=E2=80=
=99d also propose
> it should ASTs get in, they=E2=80=99re an awesome feature and it is a sha=
me we
> didn=E2=80=99t get them when we got generators.
>
> On another note, while we *could* allow extensions to hook into the AST,
> I=E2=80=99d stray away from letting them modify it and implement new feat=
ures. That
> really doesn=E2=80=99t sound like a good idea at all (I could elaborate o=
n why, but
> I won=E2=80=99t bother unless someone asks me). Letting them read it woul=
d 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 extensio=
n
> 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. Do=
es
> this cause any problems for them? While I can see the benefits of course,
> I=E2=80=99d just like to be sure that the validator doesn=E2=80=99t let a=
nything slip
> through.
>
> It=E2=80=99s also nice to see zend_emit_op and _jump, I suspect they=E2=
=80=99ll make code
> easier to read (currently I have to scan for the other operands sometimes
> as they=E2=80=99re not always set together).
>
> Again, I really like this. I look forward to its inclusion. Thank you so
> much!
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
That's nice Nik ;-)

As I told you on IRC, I'm all in for developping an extension that could
play with the AST.
I like Andrea's suggestion of publishing to userland an API that looks like
PHPParser :-)

Julien.P

--20cf302ef9f6440e0604ff8deeb6--