Actually, the best arc code IMO uses a fifty-fifty mix of functional and sequential thinking....

> my "set x" functions were clobbering each other

As a beginner you probably want to use '= instead- That's the more general command. Most arc lispers will only use 'set in rare cases.

> (def ugh (string) ...

Avoid naming the variable 'string: It will probably be OK, but since arc has functions and variables in the same namespace (google "lisp-1") you're clobbering the 'string function.

Here's how I'd rewrite this code (as far as I understand it, which isn't very far, I'm afraid so this is a very very rough approximation :-)

  (def ugh (str) 
   (let x 5
    (forlen i str 
       (let v (trunc:/ 12 (+ i 1))
         (if (is #\A str.i)
	     (++ x v)
	     (-- x v)))
    x))

If you really, really wanted to get rid of the "sets" you could write something as the following, which is in pure functional style (you might not want to do this, though... there's better languages for experimenting with a pure FP style, like Haskell)

(Again, very rough, untested code)

  (def ugh (str) 
   (apply +
    5
    (map (fn (c i)
             (let x (trunc:/ 12 n)
                 (if (is #\A c)
                     x
                     (- 0 x))))
         str
         (range 1 len.str))))

  arc> (on c "arc" (prn index ":" c))
  0:a
  1:r
  2:c
  nil

  (def ugh (str)
    (let x 5
      (on c str
        (let v (trunc (/ 12 (+ index 1)))
          (if (is c #\A)
              (++ x v)
              (-- x v))))
      x))

It's needs a lot more work though before it's worth posting publicly- Not sure if/when I'll get around to doing this.

1. Regular quoting is far simpler and has a much lower cognitive load (i.e. there are less things you have to be careful about when you use it)

2. On occasion, you need to quote data that contains commas or comma-ats without expanding anything. For instance, you may want to quote a piece of code to send to eval and that could contain a macro.

You're right from the standpoint that I hadn't noticed the similarity and should have. Your solution is probably the best yet for the example I gave.

  (def greduce (iter)
    (fn (f xs y)
      (iter (fn args (= y (apply f y args))) xs)
      y))

  arc> (greduce.map + '(1 2 3) 0)
  6
  arc> (greduce.maptable (fn (y k v) (+ y v)) (obj 'a 1 'b 2 'c 3) 0)
  6
  ; etc...

Alternatively, we could have data structures provide a left fold and automatically derive an iterator:

  (def giter (fold)
    (fn (f xs)
      (fold (fn (y . args) (apply f args) nil) xs nil)))

I feel like I can understand the primary design decisions for arc pretty well- They are:

   1. KISS (Keep It Simple, Stupid)
   2. Code brevity (note code.arc for pg's thinking on this)
   3. Don't make the code look like line noise

From what I have read, Arc goes much deeper in its design principles. Those can be enveloped as the thorough "bottom-upness" of design: both read & write access to the language, right through to its primitive elements.

And this is the direct result of Mr. Graham's popular relation of Arc's design philosophy (http://paulgraham.com/design.html): a programming language ought to strive to accomodate those who themselves are qualified to design languages, translators and compilers, among other things.

This is at the foundation of Lisp, and Arc is a promising language because its designers seem to have well understood that foundation.

Your 'best alternative for my example is extremely clever, but doesn't work:

  > (= *list-of-numbers* (6 2 4 5))
  > (best (fn (a b) (and odd.a (> a b))) *list-of-numbers*)

  6

  (best (fn (a b) (and odd.a (or even.b (> a b)))) '(6 2 4 5))

  best[[a;b]-> odd[a] and (even[b] or a > b); list[6;2;4;5]];

  (mac focus (var . body)
    (w/uniq (storage unbound)
      `(withs (,storage nil
               ,var (fn ((o arg ',unbound))
                      (if (is arg ',unbound)
                          ,storage
                          (= ,storage arg))))
         ,@body  
         ,storage)))

Something else that would be hard to develop, but possibly pretty innovative, is if an arc package system were tied to a git-like patching system:

This means that a package could "modify" instead of just "adding" to the code.

In most languages, this wouldn't be a feature that makes sense. In those languages, packages simply override code instead of mutating it. However, since a central tenet of arc is to have extreme minimalism, it would be interesting if packages could avoid adding unnecessary bulk to the base language by allowing mutation of existing code.

So, for instance, a package that improves a basic arc language feature could actually "clean out" the previous version of the code right out of the base language. (The packaging system would of course retain a copy of the old code, in case the package is ever removed and the previous code needs to be restored)

Or, a package could just be a patch on a core file (like ac.scm) that enhances the core in some way. This way, a package system could be used even for aggressive language experimentation.