In order to get to the arc prompt, you'll need to run the application server (asv) in a separate thread, you can do so with the following code:
(= app (thread (asv)))
and, you can stop the server with the this code:
(break-thread app)
Once Arc's app server is running in a separate thread you'll have full access to the Arc repl and you'll then be able to modify your application on the fly.
I wanted to add one more source. This tutorial just popped up on Reddit this morning and covers the creation of a web app using Common Lisp, Hunchentoot, CL-WHO (HTML generation), and ParenScript (for Javascript generation). I haven't had a chance to read through it just yet, but it looks very thorough and easy to understand.
Arc Forum user brett (http://arclanguage.com/user?id=brett) has posted a very nice webapp that uses Arc to allow a runner to log their daily distances and see some stats on the numbers entered.
I've not deployed my own Lispy web app just yet (though I hope to very soon), but I can definitely recommend some resources for you that I used when I was doing my research on which Lisp alternative to use for web development.
First, the two main alternatives that I found were the ones you listed above, i.e., the PLT Web Server or Common Lisp w/ Hunchentoot. For the first one, I found two great resources, the first is from one of the PLT team members and is a small series on how to develop a reddit clone with the PLT Web Server--here are the links:
If your looking for a case study on using PLT to develop a website, then check out the paper by the guys at Untyped (http://www.untyped.com/)--they seem to be using PLT Scheme for nearly all of their web-based work--that describes their experiences in using the language/web server:
Also, Ethan Herdrick has developed the website Biographicon (http://www.biographicon.com/) using the PLT Web Server as well.
Now, as for Common Lisp and Hunchentoot, the best example I've found of how to get a site up and running has been the LispCast project which can be found here:
For a good case study check out Brian Carper's blog. He has created a website that showcases his love for Origami using SBCL + Hunchentoot and he's blogged about it quite a bit. To checkout both his personal blog and the origami site, try here:
Those links should be enough to get you started in your research. Wish you luck, and remember to share your experiences regardless of which route you decide to go so that others that decide to follow in your footsteps will have an easier time getting started.
One way to stop the Arc application server (i.e., app.arc or asv) is to run the server in a separate thread and kill the thread when you want to stop the server, like so:
(= app (thread (asv)))
and, to stop it:
(break-thread app)
This will allow you to get back to the Arc prompt without pressing stop in DrScheme.
As for your second problem, the reason you are having trouble is that you are typing in the URL for the hello operation. You need to use http://localhost:8080/hello2 instead where the portion after the / matches the name of your defop.
Not sure if you're still reading this thread or not, but I thought I would try to clear up some of the questions you have here for you.
> so now im running anarki in dr scheme right?
Well, not exactly. MzScheme is the name of the Scheme programming language implementation that you are running anarki in, DrScheme is basically a nice GUI front end to the MzScheme language.
> what was this GIT stuff i downloaded? i thought it was some sort of IDE?
No, Git is not an IDE. It is software that is used to manage source code. In other words, using Git, you get a history of changes made to your source code allowing you to rollback changes and create new branches where you can develop new features without fear of breaking the currently working build of your software. The reason you downloaded it is because it is the source control software that the Anarki developers are using to manage the Anarki source code, so you need it to get a copy (i.e., a clone) of the current working version of Anarki.
> what do you use to edit/compile? is there something better than DrSceheme?
Everyone uses MzScheme to compile and execute Arc code, because that is the language that Arc was written in. There are other implementations of Arc on the JVM (aka Java Virtual Machine) and another that compiles to C, and I believe one in Common Lisp, but none of these are official implementations of Arc (i.e., created by Paul Graham). As for editing Arc code, well you can use whatever you want to edit it. Personally I'm an Emacs fan, so I use it for all of my editing, but I'm sure Vim, TextMate, etc., etc. would do just as well. If you are looking for an editor in which you can also execute your code, then Emacs or DrScheme should work.
I hope that clears up a few of your questions for you, good luck in your studies.
jmatt explained why you are having trouble with the second parameter, essentially its a list and not a number like the '+' function is expecting. You could write your macro this way to expand the rest list into individual parameters to the '+' function:
(mac meta (x . y)
`(+ ,x ,@y))
I think this macro works a bit more like you are expecting it to.
Everything returns a value in arc, at least nil, or any other value. When you evaluate something through the REPL, the result is displayed. When you call 'pr, all the args are displayed, then the first arg is returned (then, displayed by the REPL).
If you type, say
(for i 1 10 (pr 1 2 3 4 5))
You will not see the 1 repeated on each iteration. It will print nil, though : that's the value returned by 'for.
That's quite interesting. After reading through your explanation it makes perfect sense why I am running into this problem. Thanks for the answer and for such a fast reply to my query.
The portability thing was my initial thought on why he chose to eschew first class continuations for a closure-based CPS architecture. For some reason I decided to read over his "Lisp in Web Applications" essay again and I noticed that the mechanism he was using in Arc was described in perfect detail in his essay, and that got me thinking--was he just using this method because that's what's been in Arc all along? Are there other advantages outside of portability to different implementation languages that can be derived from using closures vs native continuations? Now that Arc is finally available for human consumption and running on mzscheme is there any barrier to porting the srv.arc application to a native continuations-based architecture?
These are just the thoughts I have wondering around in my head as I read through the Arc source. I think Arc is valuable for two reasons: 1) as a language to get things done, 2) as a crash course in language and library design. The second attribute of Arc is the one I find most interesting as it's rare that we get to look into the design of a language and its libraries at such an early and still uncluttered state. Add to that the fact that it's written in Scheme and you have a perfect case study for stimulating conversation.
Anyway, just my thoughts. I appreciate the response, and I'm hoping to get a few more, perhaps even one from Paul himself.
