Re: Re: [PHP-DEV] $obj->attr::method() is not allowed

On 2012-09-04 04:17, Laruence wrote:

On Tue, Sep 4, 2012 at 12:05 AM, Andrew Faulds <ajf@ajf.me> wrote:

On 03/09/12 17:03, Laruence wrote:

It is great parser(simple and fast) which make php works well for years..

No, it's not, it's overly complex. You have to define all sorts of different expression and variable variations :(

if you don't, you will get a complex executor.

rewrite the parser for what? for more academism?

No, because current one is constraining implementation of some things, and making some things impossible. (we are limited, for instance, in options for order that generator expressions (e.g. Python's [i*2 for i in range(6)]) could be)

we will rewrite it soon or later, but it's not because current one is bad, it will because a better parser tool shows up...

Well, current one is bad. It only works well for some common cases. For others, it doesn.t

I really don't get it, you are saying current is bad, but every language has defects, either parser, or executor. The problem is that the only formal definition of the language _is_ the parser - there's no grammar outside zend_language_scanner.l/zend_langauge_parser.y.

As well as making for a language full of special cases and gotchas about what expressions can be written where (and this thread only mentions a couple - everyone here can think of others) it also gets in the way of writing tools that work with the language. The developers of phc (http://www.phpcompiler.org/) ended up having to write their own AST-based grammar (which may possibly serve as a starting point for a grammar rewrite) because PHP's own parsing of even simple expressions is so long-winded and unintuitive. That site gives a couple of examples: (for 'printf("Hi!");' (27 nodes, including "r_variable") and '$a->b->c' (26 nodes, including "base_variable_with_function_calls")). Morgan L. Owens