Should we not start a new forum called the Anarki forum? After all, this forum already suffers from this dichotomy and could benefit from a clean separation.
Plus add on the fact that we can't accomplish very simple things like a front page guiding new users is embarrassing. And although we could create another added resource I find front page management is really important. It would save us all from having to answer the same question 50 million times over. I, for one, would never come back to this forum if the active & engaged community members were to move over to a new one.
I am also writting my own toy lisp: Muddy Scheme in Tcl. I am planning to implement R4RS and to add all the feactures of Arc (without continuations and with different thread model). I want to try if is possible to have one interpreter with two modes scm/arc, only changing the eval functions and special forms.
Of course It is too slow for real use, It is just a learning tool (I even had to learn how to do the mark and sweep garbage collector).
"This interpreter tries to follow the awesome "Scheme from Scratch" articles written by Peter Michaux." I learnt alot from his code too! I thought about doing some thing like "implement R4RS" eventually but figured I should learn a bit more about lisp first. I think its possible to do scm/arc together.. I'm not sure you even need to change the eval function...
Smart-ass answer: once you build up to mzscheme, you can run Arc. ;)
To elaborate: Scheme and Arc aren't that different to implement. Parsing & literals are largely the same (Arc doesn't use booleans, vectors, et al.), Lisp constructs are fairly standard (quote, if, assign, fn, etc.), and Arc even borrows high-level features like TCO and continuations. Scheme uses hygienic macros, which seem harder to implement than Arc/CL-style macros anyway. Moreover, Arc is simple: the "primitive" things are in ac.scm and the "meat" is in arc.arc. Once you get the Scheme side working, you get the rest of Arc for free.
Good series, though. With the above in mind, it'd be pretty easy to tweak Scheme-from-Scratch into Arc -- and a good exercise, at that.
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):
The HN link to this post make me feel that there is something wrong with all the news systems when the content of a link is taken outside of its original context.
