git://github.com/pauek/arc-sbcl.git

As for your concerns, I think you shouldn't be too worried. Just check it out, there is ample room for improvement, especially in speed, which I understand is your primary objective. No network yet, no threads, continuations are implemented as chains of closures (I honestly don't know better than that)... it just loads plain arc.arc, and I haven't checked it thoroughly.

For me, this was a very nice opportunity to learn about the CPS transformation. Arc is perfect in this respect (only 4 special forms). I'm pretty sure that, as an exercise, it's full of bugs and misconceptions, because I love to learn by doing (and make lots of silly mistakes along the way)...

  A foreing function interface

I also wanted to mention a fourth benefit that I think modules can offer, which is:

4. They allow some form of management of dependencies between pieces of code.

"The kind of modularity provided by packages is actually a bit odd. We have modules not of objects, but of names. Every package that uses 'common-lisp' has access to the name 'cons', because 'common-lisp' includes a function with that name. But in consequence a variable called 'cons' would also be visible in every package that used 'common-lisp'. If packages are confusing, this is the main reason why; they're not based on objects, but on their names".

In my case, I kind of think about it as "typographical" reasons. For instance, all manuals of typography tell you that it's uncomfortable to read very long lines of text if they are too close (in fact, this forum is above the limit, whereas PGs essays, if you remember, are almost perfect). The reason is that when you try to find the exact line that is the continuation of the one you are on, you have to search. Best measures for this have been tabulated by the professionals, of course. And, you know, lately I've discovered myself trying all the time to make programs not surpass the 65th column, and using the "wc -L" command all the time, so that programs occupy mostly your field of vision without moving your eyes... Stupid maybe? Perfectionism? Yes, I know. But I think this goes in the lines of your comment, since documentation breaks this 'unity' of code, I don't like it in the middle.

And the one thing that has attracted me towards Arc is, as a matter of fact, "the PG style", this minimalist, amazing (for my taste) coding style that I saw in "On Lisp" and "ANSI Common Lisp". It feels right to me, and you feel that code becomes a 'definition', so I now think I should be trained enough to read "arc.arc" _without_ documentation, as if I was reading math or something. And since Arc seemed like a language built with those principles, the addition of documentation, while certainly useful, didn't feel right to me.

  (def qne (obj q)
    (atomic
      (++ (q 2))
      (if (no (car q))
          (= (cadr q) (= (car q) (list obj)))
          (= (cdr (cadr q)) (list obj)
             (cadr q)       (cdr (cadr q))))
      (car q)))

  (mac in (x . choices)
    (w/uniq g
      `(let ,g ,x
         (or ,@(map1 (fn (c) `(is ,g ,c)) choices)))))

  (mac on (var s . body)
    (if (is var 'index)
        (err "Can't use index as first arg to on.")
        (w/uniq gs
          `(let ,gs ,s
             (forlen index ,gs
               (let ,var (,gs index)
                 ,@body))))))

  (from "arc.arc")
  [mac] (in x . choices)
   Returns true if the first argument is one of the other arguments.
      See also [[some]] [[mem]]

  (from "arc.arc")
  [mac] (on var s . body)
   Loops across the sequence `s', assigning each element to `var',
      and providing the current index in `index'.
      See also [[each]] [[forlen]]