wow.
Let's say it's possible to call any library in any language(I've no idea how:) )
and we are able to do that (only) for s-expression based languages, we are set. We can use all the libraries of those languages, as Arc evolves.
Arc is listed among the [Parrot-supported languages](http://parrot.org/languages). Dunno what kind of shape the implementation is in though.
Parrot is having regular releases, and Rakudo is coming along, so I wouldn't call Parrot vaporware.
Also, my understanding is that code running under any parrot-hosted language can call code from any other parrot-hosted language. I haven't tried this out yet. This would, of course, be very nice for Arc.
Autor here. The implementation on github is for arc 2 and is really outdated. I've got a lot of improvements, including support for arc3 and a self hosting compiler that I haven't released yet. I've stopped working on it after seeing how slow Parrot is at the moment (or at least how slow it was a few months ago). The implementation is quite complete and can load a slightly modified version of arc.arc (mostly to avoid overriding internal functions) but could be easily modified to load the official arc.arc. To give an idea of how slow it currently is, just loading arc.arc takes a few minutes (but it can be pre-compiled, so startup is fast). On my computer it took something like 9 minutes, after an optimization to my code generator I brought it down to 4 minutes, and after a new release of Parrot it went back to 9 minutes (without changing my code, it was the VM's fault). After that, I stopped the development. Another show stopper is that just spawning a new thread makes the VM segfault, thus preventing me to run a slow version of news.arc.
If someone is interested, I can push this new code to the github repo. It probably needs some modifications (not too many hopefully) to work in the latest Parrot, since they've been changing a lot of stuff in the last months. Keeping up with these continuous changes is also among the reasons why I stopped the development. Every month, after a new Parrot release, something broke because the API, or the build system, changed.
I believed that after the version 1 there should be any modification in the API. You have the same problem with Parrot than the rest of the developers. I think the only proyects that are still update are Partcl and Rakudo.
I follow Partcl becouse I am a Tcl user. It is being rewriting in NQP. The Pir version could pass 4089/7397 test from the official test suit. It a lot slower that the official version.
Can you explain how is possible(theorically) to use libraries from various languages with another language in Parrot? The library have to be compiled to Pir?
They're still deprecating stuff after every release, and the following month deprecated stuff is removed.
All languages on Parrot compile down to a common denominator, Parrot's assembly language (PIR), either dynamically at run time or before execution. It has an object system and common function call conventions, this means that as long as a language supports calling functions and a compatible object system (or some wrappers around it) it can call any function and use any object as other languages running on the VM. Arc doesn't have an object system, so some wrapper would be needed. To get seamless interoperability the language implementation should define a mapping between the language's primitive types and the corresponding Parrot's types. Primitivearc currently lacks the wrappers around the object system to interoperate with object oriented libraries (adding them wouldn't be a huge task I think), but it can already call any function loaded into the VM. To call a Perl 6 function (this doesn't work because 'load assumes an Arc file but it could be easily modified to call the correct compiler, since the mechanism is already present in Parrot):
