On 2012-09-04 04:17, Laruence wrote:
On Tue, Sep 4, 2012 at 12:05 AM, Andrew Faulds <a...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
