Hi! > 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.
I'm not sure - why exactly is it a problem here? I can understand how having such document might be useful and interesting (not useful and interesting enough that for the last 10 years anybody bothered to do it but still, I can imagine) - but how existence of such document would solve your problem? > 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")). I don't see any relationship between the fact that implementation of separate compiler required separate parser (which is only logical since existing parser is built to suit the needs of existing compiler and not whatever needs phc authors had) and the parser being "unintuitive". I also do not see how the number of states the parser passes is a measure of anything and why 27 should looks like a horrible number. There are a lot of things that can happen in expression, in function call and in function argument, the parser must understand it all. As for r_variable, it's just an expression that is not writable (i.e., no printf("Hi")=1) - what's so strange about it? -- 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
