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):
Just curious, what don't you like about Lua? (I think I read that they use 1-based (instead of 0-based) array indexing. That seems like it might be annoying.)
Lua looks good to me. I was trying to see the performance benchmark from the shootout link, but it's down. I'm pretty sure I put Lua along with python. Docs/libraries are great, but is on the slower side. Lua is on my list to learn :)
I'd probably look for something very different from Arc -- something at least partly complementary. However, I don't know what that would be. What language would at least somewhat complement Arc but not be a low-level language like C?
I wouldn't recommend Ruby because I was not happy with the state of their docs and it didn't seem different enough from Perl or Python to warrant a major effort.
I wouldn't recommend Perl, because Perl is mostly for getting stuff done. If you want to get things done, use Perl, but if you want to learn a language for the intellectual gratification of learning something new, Perl might not be the best for that.
Java is mostly a verbose Python, so I wouldn't recommend that either.
Python works well enough. Not terribly interesting, imo.
Erlang seems pretty heavily focused on concurrency, so unless you need that I probably wouldn't specifically recommend Erlang.
I've heard Lua is simple and tiny. That might be interesting.
I've started haskell. I chose haskell because it appears there is a good balance between performance/documentation/libraries. I already know one language that can be slow, so I think learning a language that's blazing fast will balance the mix. And although Python/Ruby have better docs/libraries - they are much slower than even scheme/arc. Erlang docs are horrific. IMHO.
You came to pretty much the same conclusions I did. I'll probably try out Haskell too. It fits nicely with the kind of side-effect-free-even-to-the-point-of-monads-and-arrows programming I try to do in other languages anyway, and the main thing keeping me away from it has been a perception that it had a really slow implementation.
What I had ended up voting for in the poll though was Clojure. I figure it's lenient about types, it's very reliably cross-platform ('cause of all the business interest in maintaining Java), it has better documentation than Erlang, it can still communicate with C and Erlang (as pretty much any language can, apparently), and beyond that, it has a language-level focus on communicating with other JVM code, which should give you good access to lots of other well-worked-on codebases. As far as I can tell, once you've got access to C and JVM libraries, Python libraries are the next gold mine, but I don't know how to access those libraries except through Python somehow (like through system calls or something), so it didn't affect my decision. (Incidentally, for many of the same reasons I recommend Clojure, I'm hooked on Groovy, but I did consciously try not to let my own criteria make a difference.)
In any case, yeah, now that I see it as fast, Haskell looks great. :-p
I wonder if it's possible to build the beautiful arc syntax as a layer upon haskell. Probably not doable ~ macro's/expansion and all, but still - would be awesome.
Liskell sounds very close to what you're thinking about. Also, the "Write Yourself a Scheme in 48 Hours" Haskell tutorial might interest you. I think this is a pretty popular train of thought. ^_^
That's actually where I'm starting with Haskell. It turns out Haskell is a much more natural home for Blade (my pet lisplike) than any of the other languages I've tried: JavaScript, Groovy, Arc, and Blade itself (with an intent to port/bootstrap it). It's almost scary!
