

Pharen: A lisp that compiles to PHP - yarapavan
http://scriptor.github.com/pharen/index.html

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

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

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

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

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

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

------
mahmud
This actually doesn't suck. I was expecting something much much worse, but I
was pleasantly surprised. If the author just focuses on a few primitives and
how to make them as efficient as possible (i.e. closure efficiency, tail-
calls, macros, efficient list representation, etc), if he just gets those
right, others can always use it as a target and develop more comfortable lisp
substrates on top of it.

Cheers!

~~~
Scriptor
Thanks Mahmud :)

Efficient sequences are what I'm working on right now, particularly trying to
make persistent versions of the major data structures in PHP.

Tail calls are another thing, though with PHP 5.3's gotos they could be done
(who'd have thought that feature would ever be useful?) Could you elaborate on
how I could improve efficiency for macros?

~~~
mahmud
Macros don't need to be efficient, only accurate :-) Don't sweat hygiene too
much, just implement GENSYM and you should be fine.

------
joshfraser
Don't forget to run it through HipHop to compile the PHP down to C++. :)

------
jacquesm
Hey Scriptor, neat project!

What are the major differences between Pharen and Lisphp?

(covered here:)

<http://news.ycombinator.com/item?id=1488160>

~~~
Scriptor
The big one is that Lisphp is an interpreter while Pharen is a compiler.
Lisphp takes source code and just runs it, which means that it's lisp code
running on Lisphp, which in turn is running on the PHP interpreter.

Pharen generates regular PHP source files that you can then throw wherever PHP
works.

~~~
jacquesm
How do they compare performance wise? I've tried some 'toy' lisp programs in
Lisphp and was pretty disappointed at the speed, does Pharen fare better in
this respect?

~~~
Scriptor
I haven't done any real benchmarks, but theoretically Pharen would have at
least the same order of magnitude performance as regular PHP. The main things
slowing it down is the memory overhead needed for using lexical scope.

------
mkrecny
Is the intended user a Lisp programmer forced to work on a php code base...or
a Lisp programmer looking to take advantage of some of php's native server
scripting features?

~~~
mahmud
HAH!

I think, strictly, the former.

(I actually laughed out loud at this :_)

~~~
mkrecny
Fair enough. I've never programmed in lisp. I just assumed that lisp didn't
have native server abstractions like $_REQUEST - and that Pharen may expose
those.

~~~
randallsquared
While no or few lisps have that sort of thing baked in natively, they mostly
have libraries that expose it, which is arguably better in any case.

------
kaiwetzel
From reading the examples this looks awesome, I'll give it a try tomorrow at
the office. Is there a way to expand macros only and not do the compile-to-php
step?

My current project involves generating php from a declarative definition and
this could be just the right tool for the job! Maybe it will make switching to
common lisp a lot easier once I learned enough of it :D

~~~
Scriptor
>Is there a way to expand macros only and not do the compile-to-php step?

So that it would just generate the Pharen code resulting from the expansion?
Unfortunately, not yet. As soon as a macro is done executing it returns the
node tree itself, which is then compiled. There might be a way to hack macro-
expand in though.

Let me know how trying to work it into your project goes! I'll be glad to help
with any problems that come up.

------
ecounysis
This is great. I just started on a lisp to php system a couple weeks ago - for
many of the same reasons you did. How can I help with this?

~~~
bergie
Start here: <http://scriptor.github.com/pharen/contribute.html>

The project is on GitHub, so submitting patches is very easy.

------
jhuni
Is this modeled after any particular Lisp? It looks a little bit like Clojure.

~~~
Scriptor
I'd say it's closer to Clojure than others lisps, but there are still some
differences. For example, no keywords (:foo, :bar, etc.) and lists are not
functions of their members. This can get a little confusing with Pharen's
array access syntax:

    
    
        (:some-list 1)
    

Here, some-list is just a variable while the : prefix tells Pharen that you
are trying to index into it.

------
d0m
I pretty much like the partial such as (map (* 2) [1 2 3]). Do you plan on
adding something like (map (/ _ 2) [1 2 3]) like Arc or a #(.. % ..) clojure
equivalent?

~~~
Scriptor
Possibly, it might have a use in some web framework ideas I have (such as
designate a series of actions to perform on something like input data).

------
clyfe
List of languages that compile to PHP

<http://news.ycombinator.com/item?id=2076631>

