(parameter foo ...)
  (w/foo ...)

  (= foo ...)
  (w/ foo ...)

  (var foo ...)
  (w/ foo ...)

Another difference is that keyword arguments are no longer supported at all. This is because it's quite difficult to implement them properly, only a single function in Arc/Nu actually used them, and they're not backwards compatible with Arc 3.1, so I decided it wasn't worth it.

  (mac parameter (x y)
    (w/uniq (var body)
      `(do (var ,x ,y)
           (mac ,(sym:string "w/" x) (,var . ,body)
             `(w/ ,',x ,,var ,@,body))
           ,x)))

If you mean you'd like to use Arc's http server from Racket, the answer is yes, you can write your programs in Racket and use Arc libraries if you want to. It's currently rather awkward, but we can help you with that if you want.

Or if you mean you don't want to be running any Arc code at all, I suppose you could translate the Arc library you want into Racket. I can't quite tell why you'd want to do that, because it would be a lot of work and you would end up with a library that did the same thing anyway as the Arc library you already can use anyway.

You also asked if there's an "automatic" way to translate Arc into Racket. The answer to that as rntz explained is yes, that's what the Arc compiler does. It takes Arc code and translates it into Racket. But that's really the same as option one.

Perhaps you're asking if there's an automatic way to translate Arc into readable Racket. No, the Arc compiler produces a giant blob of Racket code. The Arc compiler produces working Racket code, but not code that you can look at and see what it's doing (not without a lot of work, at any rate), or to be able to modify yourself at all easily. So the answer to the question "is there an automatic way to translate Arc code into Racket code readable by humans" the answer to that one is no.

It's actually kind of an example in (the most advanced part of) the Racket getting started pages:

> Given the "many" example, it’s a small step to a web server that accepts arbitrary Racket code to execute on the server. In that case, there are many additional security issues besides limiting processor time and memory consumption. The racket/sandbox library provides support to managing all those other issues. (http://docs.racket-lang.org/more/index.html)

The racket/sandbox module reference has another example:

> For example, here is a quick implementation of a networked REPL... (http://docs.racket-lang.org/reference/Sandboxed_Evaluation.h...)

I've been using feedreaders for about 4 years, but I still remember that I went past the RSS icon several-score times before I figured out what it meant and how I should use it. I think the notion of subscribing is a huge reason feedreaders haven't caught on in the mainstream. So goal #1: to give the benefit of feedreaders - one place to read - to lay users without requiring them to create subscriptions. On readwarp you just vote on what you like, and you get subscribed to feeds behind the scenes.

Even if you understand feedreaders, they have several issues. First, since they sort by time, one high-volume feed can swamp others. This implicitly gives people an incentive to post more frequently rather than with higher quality (http://akkartik.name/blog/2009-05-19-21-30-46-soc). Second, feedreaders today look too much like my inbox. At some number of feeds google reader starts to seem like work, and I start skimming rather than reading. So goal #2: to be fair to all my feeds, to eliminate the sense of 'falling behind', and to force me to not skim. The current UI forces me to focus on one story at a time, even if I hit the red button within 3s of looking at a story.

Goal #3 is to be less concerned with social recommendations than, say, stumbleUpon. Reddit tried to do recommendations by clustering users, and it failed partly because we all have such diverse interests, just because I overlap with you on programming doesn't mean I overlap with you on indian news. A special-case of 'not being social' is to not be concerned with what's popular. What we all read should drive what's popular, not the other way around. But lots of sites today will just show you what's popular, simply because that's easy to do. When we all tend to read what's popular, the people who read a lot end up disproportionately influencing what we read. No conspiracy theory here, I just want us to make more independent reading choices, and I think that'll improve our level of discourse and make the world a better place.

The implication of goal #3 is that I use more text mining than graph algorithms to make recommendations. I'll prob factor in recommendations from your friends at some point, but it'll just be one signal among many to decide what you should read. The program currently is about 4k lines of arc. Much is going on behind the scenes that the current UI doesn't really expose. There's algorithms to prioritize your feeds based on affinity with other stories you said you liked. Subscription isn't boolean but grey-scale. But the current UI doesn't separate multiple users, and it's trying to minimize how much you tell me about yourself. If you'd like to try out a feedreader personalized to your tastes, send me an email. I'll import your feeds for you, and you can try out my algorithms to prioritize your feeds.

"I like reading all of the feeds from one source and then switching to another"

That's the sort of thing that would be a trivial change for readwarp. I've received this feedback a couple of times, and have been mulling a 'more from this feed' button.

  (tag body
    (tag div
      (map display-thread threads)))

  (tag body
    `(tag div
       ,@(map display-thread threads)))