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?
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".
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.
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.
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.
> 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:
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.
> 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.
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.
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?":
Anything else?