Arc, is, for the moment, written on top of MzScheme. that presents a bit of a problem, because writing extensions to Arc entails first writing an extension to MzScheme and then writing some glue to allow the extension to be used from within Arc. This is a bit of a mess. It would be nice if C extensions could be created for Arc directly, but that would probably entail the development of a standalone Arc built on C code somehow (either directly or via a technique similar to how they built Scheme48). Ruby took this approach, and it is at present so easy to write a C extension to Ruby, almost as easy as actually writing Ruby code, that it puts most other scripting languages' extension mechanisms to shame (cough...cough...Perl).
By the way, being able to call the best libraries written in other languages also means that you wind up thinking in those languages as well, rather than in Arc. My experience comes from Ruby, and in many cases a Ruby library written with Ruby's idioms in mind, wrapping an underlying library written in C, trumps a library wrapper written by means of an automated tool such as SWIG any day of the week. The same would probably be true of Arc as well, once this aspect comes to pass.
I notice the Arc source is littered with a few references to Scheme 48, specifically things not working in it. But if that got fixed, then you'd have access to C libraries, because IIRC Scheme 48 was built to interface well with C.
The only thing that seems to affect, going by comments, is the conversion from characters to integers and vice versa. If that's the only actual problem, there are only about ten places in the Arc code that need some replacement fix.
