Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62848
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50485647.1060102@hoa-project.net>
References: <CAF+90c-+Hgcv5B4+eGDS+jEj6oNoyefBWO-M=kvThaVdckz62g@mail.gmail.com>
	<504836A3.20904@zend.com>
	<50485647.1060102@hoa-project.net>
Date: Thu, 6 Sep 2012 09:01:54 +0100
Message-ID: <CAPwsocGPS7JOxn_Lwx4VZziYrse51aMji3JYx_Aj_Y5EVe4v0w@mail.gmail.com>
To: ivan.enderlin@hoa-project.net
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf307d04d29ec35204c903e7a1
Subject: Re: [PHP-DEV] Moving to an AST-based parsing/compilation process
From: leight@gmail.com (Leigh)

--20cf307d04d29ec35204c903e7a1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hi

> The lexing and parsing processes will not be slower than actual, and the
construction of an AST is a new process. Well, as usual, new process
requires new resources. But if we look further, it will certainly be a nice
tool to perform better opcode caching, it will remove a lot of hacks, it
will allow third-part tools working on safeness, security, quality etc. to
go deeper at low-costs which is very important for PHP community, it will
facilitate future works

I think this is a good point to focus on, there has been a lot of comments
about the increased resource cost of the parse. What is being forgotten is
that you can offset this against all of the gains you will see as a result.

Maybe the upfront cost of a parse goes up, but once it is parsed and the
opcodes are cached, you won't have this cost again until you change the
script. Then you have all of the benefits for every subsequent request.

Increased cost once, benefits every time.
On Sep 6, 2012 8:53 AM, "Ivan Enderlin @ Hoa" <ivan.enderlin@hoa-project.ne=
t>
wrote:

> Hi Dmitry,
>
> On 06/09/12 07:37, Dmitry Stogov wrote:
>
>> Hi Nikita,
>>
>> Personally, I don't see any reason to build AST. As you mentioned
>> yourself, it will be slower and will require more memory. On the other h=
and
>> AST itself would allow to perform only very basic optimizations. Most of
>> them can be easily done on VM opcode level as well.
>>
> The lexing and parsing processes will not be slower than actual, and the
> construction of an AST is a new process. Well, as usual, new process
> requires new resources. But if we look further, it will certainly be a ni=
ce
> tool to perform better opcode caching, it will remove a lot of hacks, it
> will allow third-part tools working on safeness, security, quality etc. t=
o
> go deeper at low-costs which is very important for PHP community, it will
> facilitate future works (implementations, features etc.) for PHP=85 Moreo=
ver,
> it may be possible that compiler compilers have a better lexing and parsi=
ng
> processes than actual?
>
> Someone said that AST is more =93academical=94, yes it is and that is why=
 we
> can benefit from already done researches in this area to avoid memory
> overhead (one among others). We are not the first ones facing this proble=
m.
> It requires some researches before starting to develop this. Let's try as=
 a
> POC and we will quickly see if this is a wrong way or not.
>
> Cheers.
>
>
>
>> Also, as it's not an easy task, the old "ugly hacks" will be replaced
>> with new mistakes, which would require new "hacks" in the future :)
>>
>> The only real advantage could be an ability to expose AST to PHP scripts=
,
>> but only few people may need it.
>>
>> Thanks. Dmitry.
>>
>> On 09/04/2012 11:57 PM, Nikita Popov wrote:
>>
>>> Hey folks!
>>>
>>> Some people asked me what the advantages of using an AST-based
>>> parsing/compilation process are, so I put together a few quick notes
>>> in an RFC:
>>>
>>> https://wiki.php.net/rfc/ast_**based_parsing_compilation_**process<http=
s://wiki.php.net/rfc/ast_based_parsing_compilation_process>
>>>
>>> It would be nice to get a few comments from other core devs on this.
>>>
>>> Nikita
>>>
>>>
>>
>>
> --
> Ivan Enderlin
> Developer of Hoa
> http://hoa.42/ or http://hoa-project.net/
>
> PhD. student at DISC/Femto-ST (Vesontio) and INRIA (Cassis)
> http://disc.univ-fcomte.fr/ and http://www.inria.fr/
>
> Member of HTML and WebApps Working Group of W3C
> http://w3.org/
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--20cf307d04d29ec35204c903e7a1--