Arc Forumnew | comments | leaders | submitlogin
Ask PG: Why use CPS rather than actual continuations in srv.arc?
6 points by croach 6071 days ago | 6 comments
I've been reading through the source for the Arc web and application servers and I've had a question in the back of my mind all along. Basically, I noticed that the web server uses the continuation passing style as defined by PG in his talk in "Lisp in Web Based Applications" (http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt)--i.e., the Arc web server is using closures to implement continuations rather than just using native continuations. I was hoping maybe someone could shed some light on why this route was chosen especially since Arc was built on top of Scheme which has support for native continuations rather than CL in which case this would be the only solution available. PG, would you like to weigh in on why this decision was made? I'm basically just curious, as the implementation in Arc works perfectly fine for my purposes.


7 points by kens 6071 days ago | link

One question I have after reading that article: why doesn't Arc have keyword parameters? The article makes keyword parameters sound like the best thing since sliced bread, so it's a bit surprising that they aren't in Arc.

My guess on why the web server uses CPS rather than native continuations is that web pages inherently have many branches (e.g. multiple links), and that's easier to program with multiple continuation functions than with first-class continuations. (At least I don't see an easy way to do it with first-class continuations.)

-----

4 points by drcode 6070 days ago | link

I would guess that pg is hoping hash tables and alists can fill the roles that keyword parameters otherwise would be used for... "need keyword parameters? have the function accept an alist."

-----

4 points by almkglor 6070 days ago | link

Yes, but it's horribly inconvenient to access.

Same with defop. Accessing the GET/POST arguments to an operation is done via (arg req "foo"). It would have been worlds nicer if I could just define something like

  (defop foo-getter req
   (w/args (foo bar) req)
     (...))

-----

2 points by jmatt 6070 days ago | link

I have wondered a few times why arc doesn't have keyword parameters. It is one of my favorite features in Gauche scheme. Other great features are clos like object system, module system and a thread system that supports preemption which is hard to find in scheme implementations.

In addition, I think keywords would make the library far more transparent. Right now I still have to root around and figure out what the heck I'm supposed to pass in.

-----

7 points by almkglor 6071 days ago | link

1) pg is rumored to have actually implemented Arc several times, on various Lisps. I would assume he went for the more portable approach, one which would work on both CL and Scheme.

2) There "should be" no real difference between continuations and closures anyway. For example, in arc2c, everything is converted to CPS anyway.

-----

3 points by croach 6071 days ago | link

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.

Cheers

-----