PXP Progress Report #1

Table of Contents

After a busy month or so moving house and working, I've picked the project back up and figured a progress report was worth writing since there are a lot of people interested in the project.

The first and most important update - the project isn't dead! It's still very much alive, but time is precious resource and since this is just a hobby project it's hard for me to justify spending lots of time working on it - it doesn't pay the bills.

Now because of that, the project is going to be taking a slight change of direction. The parser is written in Rust and the parser will always be written in Rust. I've spent too much time on the parser to just throw it all away.

But. Instead of writing all of PXP's tooling (static analysis, intellisense, formatting, etc) in Rust, I'm going to be taking a hybrid approach.

PHP is my bread and butter, so right now the focus is on making the parser written in Rust usable from a PHP project.

The process there is writing a set of "bindings". I'm currently relying on FFI to do this and that process is going smoothly - I'm yet to do any benchmarks but I've got a feeling it'll still be a huge win in terms of performance.

Once the bindings are complete, they'll be open-sourced. The next stage will be using those bindings to write the transpiler. The transpiler is actually the simplest part in the project. It's more or less "change X to Y" or "extract A from B".

The transpiler will then be open-sourced too. People will be able to start using it and trying to break it (please do try). There will also likely be some syntax highlighting for editors as well, no immediate guarantees (regular PHP highlighters will mostly work).

I then want to focus on the static analyser, since that will be necessary for editor/intellisense support. I started working on this already, but it was written in Rust and whilst I like to think I'm quite good with Rust these days, my velocity is still higher in PHP.

Writing the static analyser in PHP will make it much easier to distribute, extend and contribute to which is ultimately more important. If a tool is difficult to setup and use, nobody will use it.

That said, this is the end of the report. I'll aim to do these monthly or when something big happens.

I want to spend time on this project but can't feasibly do that without support. If you would like to support my work, consider sponsoring me on GitHub.

Enjoyed this post or found it useful? Please consider sharing it on Twitter.