Seeing some of the Arc implementation made me think that Arc programs could be more portable than programs written in other lisp dialects if a) Arc had more than the MzScheme implementation and b) Arc programs could be compiled (i.e. translated) into native lisp programs.
I don't really care if they compile or not, you can always bring your interpreter with you.
1 I think some sort of C implementation is a must.
2 It would be cool to have arc written in arc - should not be too hard.
3 Paul have you started thinking of a foreign function interface?
This release has 3450 lines of Arc and 1157 lines of Scheme, so it looks like it's mostly On Arc already. About a C implementation -- looking at benchmarks, I'd be happy if it was just ported to Ikarus Scheme. (Maybe once Ikarus is done...)
Actually, quite a few features Arc uses are taken from the underlying scheme -- like garbage collection, numbers, closures, basic I/O, strings, and so on. In that case, you'll need to count most of PLT Scheme, which dwarfs Arc's 3450 lines. So Arc isn't nearly self hosting yet. But it will be.
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.
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.
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.
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.
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.
