Arc Forumnew | comments | leaders | submitlogin
6 points by drcode 5317 days ago | link | parent

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)



2 points by lojic 5316 days ago | link

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.

-----

1 point by lg 5316 days ago | link

>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 :)

-----

1 point by devlinsf 5316 days ago | link

Hmm... I'm interested in points 4 & 5 specifically. Could someone offer an explanation/post some good links?

-----

4 points by fallintothis 5316 days ago | link

First-class continuations & call/cc are notoriously difficult to explain (and indeed, can be hard to understand in code that uses them). Your best bet is to Google around for info, seeing if you can make sense of the (vast) material available. http://en.wikipedia.org/wiki/Call-with-current-continuation and http://community.schemewiki.org/?call-with-current-continuat... might be good starts.

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))

-----

2 points by conanite 5316 days ago | link

call/cc, (or ccc in arc) isn't actually used very much in the official distribution, except to provide escape routines, à la

  (catch
    (each x xs 
      (if (foo x) 
          (throw x))))
so you don't need to go all the way to the end of a loop.

The last time I looked, ccc isn't used to capture and re-use first-class continuation objects except for this escape-clause purpose.

Here's a fine article on the subject - http://www.intertwingly.net/blog/2005/04/13/Continuations-fo...

And here's a long-winded, verbose, java-oriented article I wrote last year in an attempt to explain ccc in java terms - http://www.fnargs.com/2008/05/continuations-arc-vs-java.html

-----

1 point by conanite 5315 days ago | link

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 :)

With all these questions, I can only echo fallintothis' remark that continuations are notoriously difficult to explain, and while they make for some great intellectual amusement (see Mondo Bizarro - http://arcfn.com/2008/03/arc-continuation-puzzle.html and http://arcfn.com/2008/03/continuations-made-difficult.html ), they're not practical for everyday coding.

-----

1 point by tumult 5313 days ago | link

This is what dynamic-wind is for. http://docs.plt-scheme.org/reference/cont.html#(def._((quote...)

(dynamic-wind is one of the coolest things ever)

-----