The big question is whether or not this is faster than the implementation of Arc on top of racket. Arcueid, which is an Arc interpreter written in C actually wound up to be "about an order of magnitude slower" than the racket version[0].

[0] http://arcueid-arc.org/2013/05/22/three-implementation-model...

[I think that this is interesting as a project, so don't take this a critic.]

I'd like to see some benchmarks too. But I think that this project is not a complete Arc implementation. Some parts are more trick to program and more tricky to get fast code.

For example, I couldn't find ccc in this project ( http://arclanguage.github.io/ref/foundation-doc.html#ccc ) (it's like call-with-current-continuation). A version without ccc can cut some corners and be faster than a complete version.

Racket has a lot of work and optimizations under the hood, it has a JIT compiler and some analysis to detect the parts of the code that don't use continuations and can be compiled ignoring the continuations problems.

Arc has more mutability than Racket, and in some parts Arc goes against the Racket philosophy, so perhaps a direct C implementation may be faster. I'd like to see some benchmarks.

I expect the point is to get from a C compiler to an Arc prompt with "make install && arc". Much later, if you're worried about speed, you can install a C++ compiler and libraries, compile an ancient version of Racket, and do the other steps of the original install.

You may also submit this to the Arc forum: http://arclanguage.org/forum

Could someone please explain why this is interesting, besides being yet another Lisp implementation in C? The readme is exceptionally unhelpful in this regard.

It is probably noteworthy here because Hacker News is itself written in Arc.

Honestly Arc should get another flagship/notable thing that it has been used to create...

AtomType_Pair is an oxymoron! :)

"Atom" is not a good synonym for "value"; it is a kind of value.

As I understand the code, an "Atom" is like a tagged pointer. It gets passed around by value, sometimes it contains the value itself (numbers), and sometimes it contains a pointer to something malloc'd. So an AtomType_Pair is an atom in the sense that it gets passed around by value like an atom, but it is a pointer to a malloc'd pair.

What strikes me is that Atom's are being copied by value all over the place, even when a good chunk of them don't matter. I don't know whether the optimizer can help with that or not, but it seems like there could be a lot of unnecessary copying during procedure calls and returns.