0

I think what I'm asking is this:

  1. To make PHP understand $a=<div>{$stuff}</div> one must alter the PHP parser
  2. The above can not be done in a PHP extension or even a Zend extension. To introduce new syntax one has to modify the Zend Engine.
  3. XHP does (1) as a simple extension !

What am I missing ?

Ashkan Kh. Nazary
  • 21,844
  • 13
  • 44
  • 68
  • Perhaps looking at the [source code](https://github.com/facebook/xhp) for xhp will give you the answer; but there are certainly other PHP extensions that alter the parser such as xhprof, xdebug, runkit, scream, etc.... so your #2 statement is flawed – Mark Baker Apr 26 '14 at 16:18
  • Note that the Zend engine isn't the only engine capable of running PHP: hhvm, quercus, IBM's old Project Zero are all alternatives – Mark Baker Apr 26 '14 at 16:22
  • @MarkBaker The mentioned extensions change the PHP behaviour and the way predefined functions act but non alters the PHP syntax in any ways as far as I know. Can you kindly give some examples ? – Ashkan Kh. Nazary Apr 26 '14 at 17:24
  • @MarkBaker Interesting point, you think xhp is an extension for hhvm rather than zend ? – Ashkan Kh. Nazary Apr 26 '14 at 17:25
  • No, xhp is a perfectly valid PHP extension, so it should work with the Zend engine, or with Quercus or HHVM. I was merely pointing out that there were a couple of flaws in your second argument.... from a cursory look at xhp, it appears to be acting as a PHP pre-processor; but there are other PHP extensions such as xdebug that do affect the parser directly – Mark Baker Apr 26 '14 at 17:38
  • @MarkBaker Thanks for the quick response. Yet again I'm having difficulty finding concrete examples showing xdebug affecting PHP syntax (*not* its behaviour). By the waym what is a PHP pre-processor ? – Ashkan Kh. Nazary Apr 26 '14 at 17:45
  • A pre-processor (in this case) is something that takes your basic xhp code and converts it to straight PHP code before passing it on to the lexer – Mark Baker Apr 26 '14 at 17:47
  • An example of a post-processor would be something like APC, wincache or OpCache that takes the results of the lexer/parser cycle and stores them in cache – Mark Baker Apr 26 '14 at 17:48
  • Examples of an extension that changes PHP behaviour would be runkit, which allows PHP core functions to be overridden – Mark Baker Apr 26 '14 at 17:49
  • I suspect that the only elements of PHP that would require a true change to the parser itself would be control structures; but consider that OpCache manipulates the actual bytecode generated by the parser, so even that can be changed by extensions – Mark Baker Apr 26 '14 at 17:51
  • @MarkBaker I understand your point but does this mean that another lexer scans the file first and somehow extracts some parts (perhaps according to some plug-able syntax definition) and only then the actual PHP lexer comes in ? – Ashkan Kh. Nazary Apr 26 '14 at 17:57
  • That's my basic take on it, after a cursory scan through the source code – Mark Baker Apr 26 '14 at 17:59
  • @MarkBaker Say I want to add a new operator with some semantics behind it : `1 in [1,2] // true `, `3 in [1,2] // false`. This can be done purely in extensions ? – Ashkan Kh. Nazary Apr 26 '14 at 17:59
  • The xhp method would be to take that syntax and convert it to standard PHP syntax before passing it to the lexer, so that would be possible – Mark Baker Apr 26 '14 at 18:02
  • But operators and control structures are handled directly by the VM engine, so that's something which couldn't be done easily – Mark Baker Apr 26 '14 at 18:03
  • It might be worth noting that there are elements supported by the engine that aren't implemented in PHP syntax, I recently discovered that the engine itself already supports return type hinting (available in hack, and recently proposed as an RFC for PHP) – Mark Baker Apr 26 '14 at 18:05

0 Answers0