On 2012-09-04 18:36, Stas Malyshev wrote:
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?
My problem? I'm not the one who wrote: On 2012-09-04 03:18, Andrew Faulds wrote: > > > Can't do this: > > self::$views[$path](); > > But I *can* do this: > > $x = self::$views[$path]; $x(); >But I'm certainly among those who've raised this in the past. A quote from https://wiki.php.net/rfc/fcallfcall
"What does not work currently is $foo→bar()() - since it is surprisingly hard to tell parser it's not {$foo→bar}()() - which of course is not what I want to do."
The complexity of the current grammar is working against development.
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.
>Actually, looking at the parse tree the authors gave, I think there's a bug in the diagram and there may only be 22.
How many of those things really are distinct, and how many are an artefact of the implementation? To pick just one a recent example: why is the $x in "foreach($array as $x)" such a different beast from the $x in "$x = $array[0]" that the latter could be replaced by "list($a, $b)" but the former couldn't?
For the arguments given by phc's authors, what their needs were (a PHP->x86 assembly compiler), other use cases for a language specification, and what they've done about it, I redirect you to the site cited, since they know them better than I (having worked on it for longer than I have). Mainly
https://www.cs.tcd.ie/publications/tech-reports/reports.07/TCD-CS-2007-47.pdfrather than try to summarise them here and have questions directed at the summary rather than the source (as has already happened).
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?
Then again, $a->b->c is _also_ an "r_variable", so does that mean I can't write "$a->b->c = 1;"?
Morgan L. Owens -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
