Arc Forumnew | comments | leaders | submitlogin
Ask ArcF: in Arc? (
5 points by adm 3889 days ago | 11 comments

1 point by aw 3889 days ago | link

Speculating on the future of Arc, I think it'd be fun if Arc could call any library in any language that might be useful. :-)

For example, take an Arc implementation of Roman numerals (

Rather than tediously actually implementing that challenge in Arc, well... gosh, Common Lisp can already output Roman numerals!

So one possible Arc implementation could look vaguely like

  (def roman (n)
    (lang common-lisp (format nil "~@R" «n»)))
or something.

Which is cheating of course, but in a good way :-)


2 points by adm 3889 days ago | link

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.


1 point by pmarin 3889 days ago | link

With the vaporware Parrot VM theorically is possible but I have no idea how.


3 points by garnet7 3888 days ago | link

Arc is listed among the [Parrot-supported 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.


2 points by thaddeus 3888 days ago | link

looks great

do see

also, I am guessing by the time stamps that version 2 of arc was the current build so 3.1 would likely have problems.


5 points by stefano 3882 days ago | link

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.


2 points by pmarin 3882 days ago | link

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?


3 points by stefano 3882 days ago | link

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):

  file foo.p6:
    sub foo(%tb) {
      return %tb{"bar"};

  Arc REPL:
    > (load "foo.p6")
    > (foo (listtab '((bar "Baz!"))))


1 point by s-phi-nl 3881 days ago | link

Conanite's Rainbow has a wrapper around the Java object system that you might want to look at.


2 points by adm 3882 days ago | link

maybe work on this can be resumed after, Rokudo star release.


1 point by mikemol 3877 days ago | link

You may find these two tasks to be interesting targets: