Arc Forumnew | comments | leaders | submitlogin
3 points by chandler 6129 days ago | link | parent

Regarding question two:

I've been pleasantly surprised by how easy it is to read the arc code; and this is without ever starting the interpreter (the 350/372 lag is a killer for me, as I have quite a few apps written for 372). As a bit of background, I'm pretty familiar with scheme itself, and I tend to use mzscheme (both for its wealth of libraries and cross-platform stability). I've also written a fair share of elisp over the years, and can dork my way through other peoples CL code.

At a superficial level, I like the combination of lisp-1 and t/nil; if it manages to avoid scheme's overboard strictness, all the better ( (cdr ()) throws an exception, rather than returning (); substrings, indexing, etc all need to be exact, or an error is thrown). I also really like the if-over-cond replacement.

One thing I've found is that the terseness and paren reduction make it easy to use Arc (the language) to sketch out functions in (say) html edit boxes and paper; I definitely like the "feel" of the written code. As an example, yesterday I found myself sketching out a clojure-style generic function interface, to describe (e.g.) the Arc + operater within Arc itself:

  ;; defg(eneric), this is a "switching" function:
  (defg + args
    (if (no args)                  'zero
        (all 'num (map type args)) 'nums
                                    (type:car args)))

  ;; defa(dd-method), this defines specialized functions:
  (defa + 'zero () 0)
  (defa + 'nums args (apply num-plus args))
  (defa + 'table args (apply merge-tables args))
  (defa + 'default args (apply concat (map str args)))
The Arc language itself seems to lend itself to impromptu sketches like the above, without having to necessarily fire up emacs for paren-counting and fuzzy-complete.