nfib is faster than fib because it's compiled with the knowledge that its argument is an integer. But you could make it even faster if you knew that its argument was an integer that fit into a machine word. (That might not be what you want to do with nfib, but I imagine a lot of numerical functions are going to be used almost always with numbers that fit in machine words.)

My thought is that you should be able to specialize functions for arbitrary predicates. For instance,

  (def fib (n)  ; yeah, it's a bad definition
    (specialize (and (number? n) (< n  (exp 2 32)) (> n 0)))
    (if (< n 2)
        n
        (* n (fib (- n 1)))))

  (specialize (fib n) (and (number? n) (> n 0) (< n (exp 2 32))))

  (specialize [map f _]).

  (= fmapper (specialize [map f _]))

The original value of k is the continuation of (catch throw) - a procedure which takes one argument, goes back to the let, and returns its argument as the value of (catch throw). This makes sense.

  (bar 1 2 ('foo 3) ('baz 4))

  (def factorial (n)
    ((afn (a r)
       (if (= r 1) r (self (* a r) (- r 1))))
     1 n))

  long factorial(long n)
  {
    long a;
      while (n != 1) {
        a *= n;
        n--;
      }
  }

It should be possible to write a fairly simple scanner for Arc that looks at an Arc program and decides whether it is trivially convertible to an equivalent C program. If it is, the Arc program could be converted. If, as I imagine, the mapping would let you write any C program as an Arc program, you could then argue that Arc was as fast as C.

The question would be, what about the features of Arc that aren't trivially convertible to C, like ccc? One response would be, "well, ccc is a pretty hard function to implement in C, but that's just a property of what ccc does - to implement the equivalent functionality, you just need this much complexity. A C programmer who wanted to use continuations would have to write the same function, so the slowness is not really because of Arc."

But this is really a socio-political decision, is it not? Do we (either PG or this burgeoning community of fans) prefer a benevolent dictatorship of the sort that governs languages like Perl and Ruby, or do we prefer the ramified computational episteme of modern Scheme?

There are good arguments on both sides, but I really think that letting a thousand flowers bloom (as the Scheme community has done) has great advantages. We get to use Scheme in lots of varied environments, with lots of different hardware, and with implementations optimized for lots of specialized tasks. This abundance is in part facilitated by Scheme's minimalistic standard, of course, and that has its own drawbacks -- code portability being the most serious one.

Personally, I'm not sure I'm down with the idea of a lisp optimized for "web applications" or "exploratory programming." It seems to me that the strength of Lisp lies precisely in its ability to become a language for "x programming." Ironically, PG himself has made some of the most eloquent arguments out there for this idea.

I'm an English professor who does various kinds of computational analysis on large text corpora (so things like string handling, XML, and regex are really important to me). I've been known to write programs that take three weeks to run in Java, so I'm always looking for ways to make my programs fast without resorting to C. Nothing against C. It's one of my favorite languages. It's just not a lot of fun for string processing.

Basically, I always want to go high and fast with my languages, and that's one of the reasons I like Lisp. It's a super high level language, but (in my usage patterns) it outperforms languages like Ruby (which I adore) and Java (which I find increasingly annoying).

The thing I like about my approach is the simplicity - everything expands to sets. If we had parameters, we'd probably want to modify set so that it worked on them. In that case, this approach would still work, and would be the most idiomatic way to do it.

Certainly a layered approach is a good idea: an underlying mechanism that provides bug-free dynamic binding functionality, and then a macro layer that allows people to use the functionality in a convenient and easy way.

You might be able to use set with MzScheme's thread local variables if you also used something like using "protect" to restore values on exceptions; but you wouldn't be able to use set with MzScheme's parameters because you need to specify what is the scope that you want the parameter to have a new dynamic value within.

A function, as distinct from a macro, has the property that when you call it, it will work the same way every time, even if you have provided some crazy bindings that shadow the functions it calls. For instance,

  (def prn args ; from arc.arc
    (do1 (apply pr args)
         (writec #\newline))

  (let pr (die)
    (prn 53)) ; doesn't die.

Non-hygienic macros do not have this property. That is the basic issue.

  (let pr [die]
    (prn 53)) ; doesn't die.

We already have objects like tables which act one way in functional position and another way in argument position. Can we say that you're suggesting adding a third way = setter target position?

If so, can we extend annotate in a general manner to let you define objects which have all three aspects? (And in the future, maybe, we could let people define their own, but I'm not sure yet how this would work, or what else exactly you would use it for, so we should wait on that.) Here's your example, modified a bit:

  (= foo
      (with (var1 1 var2 2 var3 3 var4 4)
        (annotate
          (fn (v)                 ; functional position aspect
           (case v
             'var1 var1
             'var2 var2
             'var3 var3
             'var4 var4))
          (fn (newv v)            ; setter target aspect
            (case v
              'var1 (= var1 newv) ; (I think these would have to be symbols)
              'var2 (= var2 newv)
              'var3 (= var3 newv)
              'var4 (= var4 newv))
          (fn ()                  ; object aspect
            (list var1 var2 var3 var4)))))

   (define (ar-tagged? x)
     (and (vector? x) (eq? (vector-ref x 0) 'tagged)))

  (annotate 'foo (fn () nil))
  => #3(tagged,foo,<procedure>)

  (attach '= (fn (v) (settercode v))
    (fn () (readercode)))
  => #4(tagged,fn,<procedure>,#hash((= . <procedure>)))

I especially like the way it wraps the expressions you want in infix and doesn't affect ones outside of its body, allowing you to use infix syntax in one place and not make the rest of the program behave in unexpected ways.

This will be especially good one we can bring readtable support (or the equivalent) into arc. I saw this suggestion somewhere:

  <3 + 4 * 5> ; syntax for an infix math form.