Scheme running on MoarVM would be nice, to be sure, if only to prove that it can be done. It would be several orders of magnitude slower because modern Scheme compilers (like modern Lisps) compile to machine code.

Connecting to the interpreter thread is one function call, and unmarshalling back to Perl 6 is a very simple and fast callback, I expect that most of the time spent on a single invocation of $g.run('(+ 5 4)') is in the unmarshalling of the single SCM cons cell back to Perl 6.

As to being more productive, I suppose I could have taken several months to learn MoarVM, read R6RS, do two or three test implementations until I worked out the approach, lost D20 SAN implementing call/cc, and gotten for my efforts a trivial Scheme running hundreds of times slower than any actual working implementation, and then still would have to write the Perl 6 - Scheme bridge, this time on MoarVM.

Or I could take a few nights to read the GNU Guile docs, write a 200-line helper library, and get Perl 6 quickly talking to a fast, debugged, and more importantly working Scheme implementation. Perl 6 is -Ofun, and while doing all of the MoarVM backfill may be fun to some, and maybe if I get into it it'd be fun to me, but right now it's someone else's itch to scratch.

All in all, I'll take the NativeCall route, and let someone that knows the MoarVM innards and loves the challenge of building a new grammar, AST generator, compiler and debugging the entire toolchain do the work. Life's too short.

I suppose it depends on what you intend to use it for; but I for one don't see a whole lot of utility in being able merely to call out to another language as a black box, like a coprocessor. I'd want my scheme (or whatever) code to be able to access my perl code & variables, just as if it were written in perl. Using a common machine like MoarVM or JVM makes this possible.

The facts that (a) it's not in the Perl 6 ecosystem, (b) it's not version 1.0 yet, (c) I haven't even added support for lists yet (need to talk to nine) and (d) I stated that it wasn't ready, should make it pretty clear that this isn't a finished product, I'm sorry if I gave that impression.

Also, if you read the full posting I'm fully intending to create a Slang::Scheme::Guile that will actually embed the language inside Perl 6 to the point of being able to write:

use Slang::Scheme::Guile;

guile-sub add( $x, $y ) { + $x $y }
[download]

Passing in variables marshalled in from another language is trivial, and clearly documented as scm_call_*, with list creation clearly documented as scm_list_*. There is an entire section devoted to a tutorial on how to create your own custom procedures and even entire object types that you can invoke from within Scheme. In fact, with a little bit of work it might be possible to let the Slang user create their own classes and export them as Scheme objects.

In fact, the time I'm taking to write this response is longer than it would take to create a sample Scheme function written in C, creating the Perl callback would take a little longer. I don't have the documentation to hand as I'm outside my development VM here, but a sample C function that exposes a color attribute from Lilypond (one of the programs that hosts a Guile interpreter) to Scheme is roughly 10 lines of code, including marshalling the 24-bit alpha mask from Lilypond's internal format to Scheme.

Also, please remember that Guile Scheme is designed to be an embedded language. Look at the Wikipedia page to see how many applications, including GNU Make, are using it as an embedded language. This is one of the reasons I chose this Scheme implementation to embed, rather than say, SIOD or some other library.

Lastly, if you'll read the Guile Scheme documentation, you'll see two whole sections devoted to letting Guile Scheme access the host application, including a lengthy tutorial on creating custom Guile Scheme types customized for your application.

If you think it's easier to (1) write a new Scheme on top of MoarVM, (2) modify the Perl 6 runtime to allow a whole new language in parallel with the existing Perl 6 binary, (3) write a new ICE-9 function library on top of your new Scheme implementation in order to call back to Perl, (4) not go completely mad writing call-with-current-continuation to unwind a stack from Scheme to Perl 6 across two interpreter threads, and (5) do this all in the time it'll take me to add an ICE-9-Perl6 function library, you're more than welcome to take on the challenge, and I doff my hat to you.