
Php-parser written in golang v0.3 is released - z7zmey
https://github.com/z7zmey/php-parser/releases/tag/v0.3.0
======
sbarre
There's a [dead] comment that asks "Why?"...

Obviously not every project needs a "why?", and this is a technically cool
endeavour that stands on its own..

A few ideas I can think of for "Why?":

    
    
        * Static analysis of a codebase looking for bad practices or errors
        * Feeding the structured output into code-gen for another language, to start a porting project
        * //STEP MISSING//, Profit? 
    

Anything else?

~~~
Xylakant
Aaron Patterson, the author of phuby
([https://github.com/tenderlove/phuby](https://github.com/tenderlove/phuby))
once explained in a talk what's good about embedding a php interpreter in
ruby. The gist, as I remember was: Technically speaking, it makes no sense. It
will never become anything useful. But you can make it work, and you might
learn something useful along the way. IIRC, he found a couple of very
interesting (and useful) issues along the way.

So the answer might just be "because I can and I want to".

This is the talk, IIRC: "Yak shaving is best shaving"
[https://www.youtube.com/watch?v=nY_Pl2x7Fgs](https://www.youtube.com/watch?v=nY_Pl2x7Fgs)

~~~
chamton
Embedding an _interpreter_ in another language can certainly be useful, but
this is just a parser.

~~~
Xylakant
Sorry, but phuby is not useful, was never intended to be and even says so.
It's a hilarious prank, if you ask me.

~~~
tyingq
An interpreter in a compiled language, though, has obvious run time benefits.
Though this is just a parser.

------
gregoriol
I think it's time: let's make a php implementation on the Blockchain

------
erikrothoff
Write PHP code and package as Go-binaries?? The potential!

~~~
zbentley
Even if this included an interpreter, that wouldn't allow you to package
anything besides the PHP runtime (e.g. the "php" executable etc) as a Go
binary.

You wouldn't be able to distribute PHP _programs_ as go binaries; it would
still be an interpreted language, so you'd still have to make sure your
programs, and their dependencies, were correctly deployed to wherever you had
installed the interpreter.

~~~
andrewstuart2
With a properly parsed AST, you could probably convert to Go's AST and compile
down to the final Go binary, similarly to how you can write a new front-end
for LLVM.

~~~
zbentley
Theoretically, you _almost_ could (with quite a bit of difficulty), but then
there's the problem of "eval".

You can "solve" that by embedding an interpreter (or a copy of your compiler)
into your runtime, but most interpreted platforms in that situation consider
the interpreter "good enough" and work on making optimizations (e.g. JIT
compilation to native code) on it rather than making a static compiler.

~~~
toast0
I mean, eval is a thing, and I'm sure people use it, but I don't recall using
it much while a PHP developer. It's just more likely to footgun than anything
else. I think you can credibly release a tool that will compile PHP into a
standalone executable, as long as it doesn't call eval.

------
xorraxrax
Why?

~~~
amingilani
Came here to ask this myself. I get that you can do anything you want to but
I'm super curious about the author's motivations. Seriously, why?

------
pknopf
What is the purpose of this? Just static analysis?

If that is it, you'd probably be better off just using the PHP parser
([https://github.com/nikic/PHP-Parser](https://github.com/nikic/PHP-Parser)).

If you are writing analyzers for PHP, you must know it enough to right an
analyzer in actual PHP. Why Go?

I can't see a lot of people using this.

~~~
sshine
> _What is the purpose of this? Just static analysis?_

I'm not sure about the "Just" here.

The opportunities for writing code transformation tools are abundant. E.g. a
PHP IDE that isn't written in PHP, a linting tool, a preprocessor for an
embedded DSL. It isn't obvious to me that the tooling for a language like PHP
need to be written in PHP.

> _Why Go?_

Go isn't a bad choice for writing parts of a compiler. The parser itself was,
however, written with the parser generator goyacc rather than native Go code:

[https://github.com/z7zmey/php-
parser/blob/master/php7/php7.y](https://github.com/z7zmey/php-
parser/blob/master/php7/php7.y)

Taking a goyacc file like this and porting it to another YACC is a lower
effort than starting from scratch. In such a way, this project delivers not
just "a PHP parser with xx% coverage in Go", but a shortcut to writing PHP
parsers in any language with a decent YACC.

One way this project is structured that I don't particularly like is that each
node in the AST corresponds to a file. For a programming language with
algebraic types (ML, Haskell), having the AST definition in a single file is
quite typical.

[https://github.com/z7zmey/php-
parser/tree/master/node/expr](https://github.com/z7zmey/php-
parser/tree/master/node/expr)

~~~
johannes1234321
> Taking a goyacc file like this and porting it to another YACC is a lower
> effort than starting from scratch. In such a way, this project delivers not
> just "a PHP parser with xx% coverage in Go", but a shortcut to writing PHP
> parsers in any language with a decent YACC.

There's already a yacc file for PHP's parser, part of the PHP runtime:
[https://github.com/php/php-
src/blob/master/Zend/zend_languag...](https://github.com/php/php-
src/blob/master/Zend/zend_language_parser.y)

