Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62858 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 21621 invoked from network); 6 Sep 2012 11:15:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 6 Sep 2012 11:15:19 -0000 Authentication-Results: pb1.pair.com smtp.mail=ajf@ajf.me; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=ajf@ajf.me; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ajf.me designates 64.22.89.133 as permitted sender) X-PHP-List-Original-Sender: ajf@ajf.me X-Host-Fingerprint: 64.22.89.133 oxmail.registrar-servers.com Received: from [64.22.89.133] ([64.22.89.133:50906] helo=oxmail.registrar-servers.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 17/B3-03079-2C588405 for ; Thu, 06 Sep 2012 07:15:17 -0400 Received: from [10.124.169.36] (unknown [82.132.242.29]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by oxmail.registrar-servers.com (Postfix) with ESMTPSA id 874F17581CC; Thu, 6 Sep 2012 07:15:05 -0400 (EDT) References: <50474A30.1090802@nznet.gen.nz> <5047D4A6.9030003@sugarcrm.com> <50486327.9050606@nznet.gen.nz> <50486C27.20200@sugarcrm.com> User-Agent: K-9 Mail for Android In-Reply-To: <50486C27.20200@sugarcrm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Thu, 06 Sep 2012 12:14:51 +0100 To: Stas Malyshev ,"Morgan L. Owens" CC: PHP internals Message-ID: <7e9600c7-d38b-4132-afb0-99ffe4c00767@email.android.com> Subject: Re: [PHP-DEV] Re: Moving to an AST-based parsing/compilation process From: ajf@ajf.me (Andrew Faulds) Stas Malyshev wrote: >Hi! > >> Well, apart from perhaps leaving them with a simpler language that >> doesn't have the inconsistencies and corner cases that currently >exist >> (and documented ad nauseum) not because of any design decision but >> "because the parser is written that way". > >If you think writing new parser gets rid of all corner cases you are in >for a big surprise. AST is not magic and parser will always be written >exactly the way it is written - so if somebody won't implement certain >feature in a consistent way, it won't be implemented in consistent way, >AST or not. An AST allows much deeper analysis of the syntax used after parsing (i.e. parsing of tokens to AST), though. This means you can be greatly more flexible with regards to a lot of things, and greatly reduce magic corner cases, such as executing a closure from a dereferenced array which is a static member of a class (something there is no good reason you can't do, just limitations of current parser) >And it's a bit late to take design decisions on existing PHP language, >it seems to me. What? >-- >Stanislav Malyshev, Software Architect >SugarCRM: http://www.sugarcrm.com/ >(408)454-6900 ext. 227 > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php -- Sent from my Android phone with K-9 Mail. Andrew Faulds http://ajf.me/