rfc:ast_based_parsing_compilation_process

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
rfc:ast_based_parsing_compilation_process [2012/09/04 19:44] nikicrfc:ast_based_parsing_compilation_process [2012/09/07 12:54] – Add link regard functions parens nikic
Line 24: Line 24:
 ==== Elimination of various quirks ==== ==== Elimination of various quirks ====
  
-Currently there is various quirks in the emitted opcodes which can be attributed to the use of a single-pass compiler. The simplest (and least important) example are the NOP opcodes that the compiler inserts at several places.+Currently there is various quirks in the emitted opcodes which can be attributed to the use of a single-pass compiler. Some examples:
  
-A more interesting example is the fact that whenever you access a static member like ''Foo::$bar'' an unused compiled-variable for ''$bar'' is emitted. The compiler thinks that ''$bar'' is a normal variable and as such creates an +  * The NOP opcodes that are inserted in several places. (Yes, this point isn't particularly important) 
-unnecessary and unused CV for it+  * Access of static variables using ''Foo::$bar'' creates an unused compiled variable for ''$bar'' (because the compiler thinks that it is a normal variable)
- +  ''$foo'' and ''($foo)'' behave differently in several places (the first can act as a reference, the second can not). For more info see http://stackoverflow.com/questions/6726589/parentheses-altering-semantics-of-function-call-result/6732876#6732876. (Some people claim that this is a feature, not a bug.)
-Other quirks (which actually influences the behavior) is caused by the separation of ''variable'' and ''expr_without_variable'' in the grammar. For example parentheses may cause subtle changes in behavior (''func($foo)'' +
-and ''%%func(($foo))%%'' have different behavior).+
  
 All these can be eliminated when an AST is used. All these can be eliminated when an AST is used.
Line 46: Line 44:
 One example of syntax that is currently impossible is array destructuring without a special ''list()'' construct. The syntax ''[$a, $b] = [$b, $a]'' that is common in other languages is not possible to implement in PHP due to parser limitations. One example of syntax that is currently impossible is array destructuring without a special ''list()'' construct. The syntax ''[$a, $b] = [$b, $a]'' that is common in other languages is not possible to implement in PHP due to parser limitations.
  
-Another example are list comprehensions / generator expressions where the result expression comes first (e.g. ''[x * x for x in list]'' in Python). In PHP only the reversed syntax is possible (''foreach ($list as $x) yield $x * $x'').+Another example are list comprehensions / generator expressions where the result expression comes first (e.g. ''[x * x for x in list]'' in Python). In PHP only the reversed syntax is possible (''[foreach ($list as $x) yield $x * $x]'').
  
 Those are two examples of larger limitations, but smaller syntax decisions are often driven by parser limitations too. An AST allows implementing many syntax elements that would otherwise be impossible. (One of the main reasons for this is that an AST based parser does not require mid-rule semantic action reduction.) Those are two examples of larger limitations, but smaller syntax decisions are often driven by parser limitations too. An AST allows implementing many syntax elements that would otherwise be impossible. (One of the main reasons for this is that an AST based parser does not require mid-rule semantic action reduction.)
rfc/ast_based_parsing_compilation_process.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1