You don't have to connect it. Copy the above into a file called 'fortune.arc' inside your Arc source code directory, then type the following from an Arc REPL:
(load "fortune.arc")
(asv)
The 'asv' function spawns the built-in web server, as shown in the blog example.
Sometimes the program fails with the error below, on clicking on the link. A blank webpage is shown. After F5 (refresh), all back to normal.
Looks to me, that the system call fails because 'fortune' returns -1.
date: 1202019843: No such file or directory
make-string: expects argument of type <non-negative exact integer>; given -1
=== context ===
subseq
memodate
srvlog
gs899
handle-request-thread
It's funny, because the with/let forms in Arc immediately struck me as quite sensible. Both include an implicit 'do', (or 'progn', for the crusty oldsters like me) and so need a bounded number of forms to scan for new bindings. In the case of a 'with' form, there could be any number of terms, to the parens around the list of forms are needed. The 'let' form, on the other hand, only binds a single identifier, so the first and second parameters to the form are always going to be the term name and value, respectively.
Here's an alternate version which uses the underlying mzscheme date-handling library; it's less "bootstrapped", but also supports formatting of arbitrary timestamps under Linux.
(Feel free to ignore the 'os-name' and 'chomp' functions added to arc.arc; they are obviously from an earlier variant of the function which used the same approach as @starc.)
Agreed, though what I'd really like is a full time/date stack built in Arc...using the MzScheme primitives is pretty ugly for a supposedly "bootstrapped" language.
There are enough other areas where Arc is coupled to the underlying Scheme runtime, though, that it's probably not worth worrying about at this point.
You can use the built-in MzScheme profiling tools; just run '(time (tl))' instead of '(tl)' to start the Arc REPL. You'll want some way to force a return from the toplevel interpreter, which may mean writing a shutdown routine for the web listener that doesn't require Ctrl-C halting the server thread, but that should be easy enough to do.
MzScheme has a better profiling facility (the errortrace collection), but using it without source information is not too helpful.
It is possible to do that (and I have a patch that does it), but it's not a quick solution.
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.
Having fun hacking with it so far, but I thought I'd bring up one compatibility glitch that hit me early on:
The definition of 'date' in arc.arc assumes a BSD-compatible 'date' binary on the host system. Unfortunately, the allowed arguments for GNU date are quite different. AFAICT, it is in fact impossible to convert the epoch-seconds timestamp format into a formatted date using the GNU version of the utility. Since the bundled web server uses the 'date' function to generate logfile names, any attempt to run a webapp on Linux immediately blows up.
I've hacked up a new implementation at the MzScheme layer using native date structs, but it would probably be worth porting a more complete date/time logic library to Arc, and relying on something like a native 'current-milliseconds' call only.
