Comment by Scriptor | Hacker News Reader

Comment by Scriptor | Hacker News Reader

Parent Full thread

Hi everyone, I'm the creator of Pharen. Feel free to ask me questions or remind me why this is a terrible idea. :)

Yes there are a lot of issues with cross-language compilers. That said, Coffeescript: http://coffeescript.org, which compiles its own language to Javascript has had a lot of success and is being used in production. So it's at least possible to use languages like this.

The extra layer of abstraction is a big hurdle. When debugging you have to find the source of the problem in the PHP, though ideally after that you can just find the matching Pharen code and go from there. One of the things on my todo list is to have at least a rough line-to-line tracker built, so that it could at least tell you the general location a problem happened, if not the exact line.

Translating docs and example code for existing libraries into Pharen is a bigger issue, I think. Mainly because Pharen emphasizes a functional style of coding while most PHP code assumes you are doing things imperatively. This is something Clojure has to deal with in terms of Java interop so again it shouldn't be too hard to get around.

In terms of efficiency there is tail recursion optimization (converts a recursive function to having a while loop at the end) and a persistent sequence library in the works that would make functional looping through a list about as fast as imperative iteration. More aggressive optimizations might come in the future.

If you're interested, feel free to contribute: http://scriptor.github.com/pharen/contribute.html. If you use IRC you can come hang out (or berate me personally) on #pharen on Freenode. Any suggestions or ideas are welcome.

> When debugging you have to find the source of the problem in the PHP, though ideally after that you can just find the matching Pharen code and go from there.

You could always just add the S-Expression that became the php code as a comment. From there it should be trivial to find it in the Pharen code.

Does this only work on the newest version of PHP? Compilation of closures, I presume, requires that PHP support closures, right?

Nope, it should work for PHP 5.2 as well. Closures are implemented using a static member on a class that handles all the lexically scoped variables, not PHP 5.3's native closures.

This makes me curious, why reimplement features that would've been built-in in PHP 5.3? After all, 5.3 is now available in most major platforms including a Ubuntu LTS release and the latest RHEL.

Other than that, Pharen looks very interesting. A minor detail is that I didn't yet figure out how to call static methods of external PHP classes.

I guess I wasn't exactly sure just how widespread PHP 5.3 was and wanted to play it safe. Also, even if new servers nowadays come with 5.3, a lot of existing code is still running on 5.2.

Then again, you could argue that people interested in such projects like Pharen are likely to have modern PHP versions ;-)

I was curious to know the same thing. I do however like the code being side by side. It helps people who know PHP learn a little Lisp.

ok, that is killer. awesome work!

This is really cool and for the most part the syntax seems to make sense.

One thing I don't understand is why there is special unnatural-looking syntax for dictionaries. It is inconsistent that comma=whitespace everywhere else. Perhaps something like:

(array "a"=>1 "b"=>2)

Note that this currently compiles to array("a", =>1, "b", =>2)

The current dictionary syntax is actually typical for lisps, particularly this is exactly what Clojure does. It's just a series of elements except in this case it's designed to look at every two elements as a pair.

What do you mean by it's inconsistent? Commas are the same both in dictionaries and anywhere else, they're completely optional.

I take that back. I had no idea that {"a" 1 "b" 2} works when I made that comment.

What is it for?

Originally, for fun!

It gives you a chance to use Lisp's syntax and mentality if you're stuck with PHP on the backend. Moreover, you have features like macros and lexical scope, which can be useful.

Fun is good.

I just wondered if it had been built for a specific project and if so what problems it was trying to solve.

It's funny - I've spent the past few years thinking about high-level languages that would compile down to lisp. Recently I've seen a number that go the other way.

Is this is a problem you face personally?

Reply on news.ycombinator.com