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