Arc Forumnew | comments | leaders | submit | dmoney's commentslogin
1 point by dmoney 6142 days ago | link | parent | on: Arc as a better "common" Lisp?

An Arc->PHP compiler could make it easy for a lot of people to use it on shared hosting. I have no idea how hard this would be.

-----

1 point by nex3 6142 days ago | link

I'm not sure PHP's really up to the task - lacking closures might prove to be a big issue. It would probably be reasonably simple to make an arc interpreter, or an interpreter for a simpler intermediate language, but performance would probably suffer.

-----

1 point by apotheon 6141 days ago | link

Why not write an Arc interpreter in Perl -- or even an interpreter for a web-centric subset of Arc? Stick the interpreter in the cgi-bin directory and use that to run your Arc scripts. Perl/CGI is even more ubiquitous on shared hosting accounts than PHP, supports closures, et cetera.

In fact, I've considered creating a new closures-based object system in Perl 5 in the past (never got around to it), which sounds suspiciously like it might have some things in common with some characteristics of Arc.

-----

2 points by pc 6142 days ago | link

The lack of closures just means the compiler has to do a little more work.

-----

2 points by rcoder 6142 days ago | link

Implementing lisp in PHP would be like trying to theme your Windows 98 system to look like OS X. Yes, it's theoretically possible, and would increase the number of pieces of hardware on which your pretty UI could run, but it pretty much defeats the point of working in a Lisp to begin with.

You'd also give up the rich set of libraries and add-ons that are the real only argument for PHP.

Plus, there's the fact that the built-in Arc application server assumes a persistent, threaded server process is running throughout the lifespan of your application. PHP scripts are a one-shot deal; any local state is thrown away after each page request unless you explicitly serialize it to the session, database, or another persistent store.

Now, if you want a different surface syntax atop PHP, that's another question entirely. You certainly couldn't do much worse than what's there now.

-----

1 point by andreyf 6141 days ago | link

the rich set of libraries and add-ons that are the real only argument for PHP.

The other argument being that you can run PHP on just about any shared host out there.

Plus, there's the fact that the built-in Arc application server assumes a persistent, threaded server process is running throughout the lifespan of your application. PHP scripts are a one-shot deal...

Nobody said it was easy, but is it possible?

I guess what it comes down to is that anyone using a shared host isn't really "serious" enough to be writing an app in Arc to begin with.

-----

1 point by rcoder 6141 days ago | link

> Nobody said it was easy, but is it possible?

Of course it's possible. The question is whether it's a worthwhile use of valuable hacking time.

I also don't suspect it's a particularly interesting problem for the people most likely to be able to tackle it effectively. Now, a native Arc compiler for x86/AMD64, that would be a nice widget to have.

-----

1 point by apotheon 6141 days ago | link

Wanna bet? I know a bunch of people using shared hosting (for economic reasons) who would probably love to use Arc.

-----

2 points by treef 6141 days ago | link

har har!

-----

1 point by treef 6142 days ago | link

that is an interesting idea. While its easy to find scheme in ruby or python, google does not give me one for php.

-----