1. Brevity is top priority. If you learn all the arc functions there are lots of clever commands that anticipate common programming idioms and allow you to write very pithy code.
2. Encourages 50:50 mix of functional and imperative code for what each does best- See the accum command for an example. (If you implement this in clojure, be sure to use the new transients feature http://clojure.org/transients)
3. The design of the web server is elegant (though still somewhat alpha)
4. Call/cc is available (this is the one thing you won't be able to implement in clojure, unless you're some kind of super-guru :-)
5. Intrasymbol syntax is a really promising idea that still needs to be fleshed out a bit.
6. Simplicity- The code behind arc (i.e. the files ac.scm and arc.arc) are, by design, is extremely simple (much simpler than clojure)
IMHO, the value of arc to someone not interested specifically in language design is lower now that Clojure is available. Clojure took many good ideas from arc and expanded on them in a way that really cut into arc's value proposition.
I still think pg's rule of "brevity, brevity, brevity" is the right approach in the long run- Hopefully someone will find time to take the best of these two Lisp dialects and create a new language in the future that rethinks "brevity" in terms of the ideas behind Clojure. (I'm think it'll take more than just a library of macros and functions to do this)
I really have mixed emotions regarding the two approaches of building on the JVM vs. building from scratch.
On the one hand, building on top of the JVM gives quite a head start in many ways, and I think it's a bit ridiculous how poor the interop situation is for native programs despite the availability of FFIs (although some/much of this may be fundamental to language differences).
On the other hand, it seems the least common denominator problem always creeps up when building on a VM plus you have an extra dependency in the chain, etc.
If the Y axis is features and the X axis is time, it seems clear that building on a VM gives you a higher Y intercept. The question is whether the slope is unduly impeded. I suspect it might be, but that's totally subjective on my part.
>Hopefully someone will find time to take the best of these two Lisp dialects and create a new language in the future that rethinks "brevity" in terms of the ideas behind Clojure.
I'm curious which particular ideas you're talking about? I've used both and I don't know what clojure brings to the table that arc really needs, besides the stuff that arc will certainly get anyway, like libraries, some kind of module system, and facilities for performance tuning. (Although I think clojure could use some better libraries, too :)
As for point 5, Arc uses certain characters as syntax abbreviations iff the special characters occur in what would otherwise be normal symbols (to the Scheme reader). So far, there's
.a ; is the same as (get a)
a.b ; is the same as (a b)
!a ; is the same as (get 'a)
a!b ; is the same as (a 'b)
f&g ; is the same as (andf f g)
f:g ; is the same as (compose f g)
~f ; is the same as (complement f)
where
((get a) b) ; is the same as (b a) by Arc's indexing
; e.g., ("abc" 0) is #\a
((andf f g) x) ; is the same as (and (f x) (g x))
((compose f g) x) ; is the same as (f (g x))
((complement f) x) ; is the same as (no (f x))
See arc.arc for the actual definitions of these operators.
There are precedence and associativity rules, such as
a!b.c ; is the same as ((a 'b) c) because ! and . are
; left-associative
f:g:h ; is the same as (compose f g h)
~f:g ; is the same as (compose (complement f) g)
To explore these more, you can use the ssexpand function in Arc:
arc> (ssexpand 'a:b.c!d)
(compose a b.c!d)
arc> (ssexpand 'b.c!d)
((b c) (quote d))
On top of that, while we're on the topic, I don't know what happens if you jump into another continuation in the following circumstances:
1. you're inside atomic-invoke, call-w/stdout, call-w/stdin, or anything that creates context that needs to be undone on the way out. The problem is that a continuation from in here can be exited multiple times although it was entered only once.
2. similarly, you're inside protect, (equivalent to "finally" in java) - is the "after"-fn called, and if so, only once or for each re-entered continuation?
3. the continuation you jump into was originally running on another thread.
I should write tests to figure out what happens in all these cases, but if anybody knows the answers I can live with being lazy :)
