Php-parser written in golang v0.3 is released | Hacker News Reader

Php-parser written in golang v0.3 is released

github.com

46 pointsz7zmey27 comments

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?

Aaron Patterson, the author of 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

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

A parser is a big step towards building that interpreter, however. Who knows what the long-term goals are or what remains closed source software.

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

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

PHP is often used because it's mature, reasonable secure these days, and has world-class encryption libraries. Lots of companies develop web applications in it....

But if you're developing a web application that you host and also want to offer a private version of for enterprise use, this is somewhat appealing because it's the first step of being able to package the PHP app within a Go binary that runs on a lot of platforms and not have to release your source code.

Sure you could write it in Go from the start, but if you already have a bunch written or want to use less expensive developers, this might work out one day.

As much as my first reaction was also "why?" writing a complex parser is a good exercise, and of course having a suitable parser is a pre-requisite for all kinds of tooling, be it analysis tools, or writing an alternative implementation of the language itself.

I guess my question isn't so much "Why would anybody build this?" but "Why would you upvote this to the front-page?"

Seems like part of a larger "I built X in Y" HN pattern.

I have noticed that "I built X <in current popular language>" typically gets way more upvotes than "I built X"...

We have a giant PHP codebase but are moving components to Go. I wonder if this has any potential to aid in machine translation.

or, why not, a first step to adding php-like macro language to your go service...

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

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

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.

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.

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.

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.

Why?

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?

Probably for the same reason I have a tendency to make earley parsers for random languages in python and C++ every now and again, something to do that's semi-productive.

If I ever get around to playing with golang you can bet there's gonna be yet another earley parser implementation for whatever grammar I'm currently looking at.

Why not?

Because we can.

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).

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.

> 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

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

> 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...

This project states that it was "inspired by" Nikita's parser, but to me that raises even more questions about its existence.

nikic/PHP-Parser is feature-complete/mature/stable and developed by one of the most knowledgeable members of the PHP internals core development team. It is the library powering many PHP dev tools; static analysis included.

I can see that creating a tool like this is an excellent learning experience, but I don't see why anyone else should care.

Reply on news.ycombinator.com