He’s also cleaning up some things so that additional backends (such as LLVM) will be easier.

It doesn’t [yet] pass all the tests, since not all operations have been implemented, and because of this, it cannot [yet] compile Rakudo, but he’s actively working on it, making regular updates.

And while the Rakudo Perl6 compiler is a complicated program, needing every last bit of functionality that NQP provides, there are quite a few programs, written in the NQP language, that his port is capable of compiling into java bytecodes, and which can run correctly on the JVM.

That includes (his version of) the NQP compiler itself. It’s fully bootstrapped, and capable of running on the jvm and compiling itself into java bytecodes.

So, the fastest way to get an LLVM port would be to make a branch from his branch, and start hacking. The downside of course would be that if he chooses to modify anything other than java-specific stuff, you might need to adjust your own code to stay compatible.

The other fast way would be to contribute to his branch of the code, so that he can merge it back into Rakudo’s main branch, and *then* make a branch on which to hack.

The first two things I have to say are actually two lessons I learned when working in the SMOP experiment, and that I still hold to be true for any low level implementation — as in, not using a virtual machine with high-level stack management — need to do.

1) Continuation-Passing-Style: This is absolutely required due to all the possible diversions that the code execution may happen (as in, phasers, control, catch and others). This is possible in LLVM using the “FastC” calling convention.

2) Representation Polymorphism: It is very important to understand that, with the exception of the native types, every Perl 6 type is the equivalent of a C++ template, in that it only becomes concrete when you choose a representation, with an important twist, you can actually use types realized in different representations interchangeably, which means that you should be able to step back and use the Meta-OO APIs to dispatch the call.

Now… I have mostly been thinking about generating C code to compile with LLVM (because of the fastC calling convention and CPS). And the way this would work is that we would generate, for each piece of NQP code, different ABI levels, from a truly-C-level call, to a completely abstracted invocation, and the compiler would be able to decide to which level it could go (depending on the actual types available in the lexical scope). The different levels would be:

level 0) the function is exposed as a C symbol with the invocation completely resolved at compile time and you can only receive native types as arguments on the stack and return native types on the stack without support for exceptions of any kind, and you can only call other functions of the same level. In that level you just use the C stack as usual.

level 1) the function is exposed as a C symbol with the invocation completely resolved at compile time and you receive non-native types of known representations (i.e.: p6object Int) and return native or non-native types of known representations by using a low-level calling convention (i.e.: no capture object). This already requires CPS (with full support for exceptions), so each function is potentially splitted in several sections as you call other functions, the function lexpad becomes a garbage-collected item. A function in this level can call functions in any other level already.

level 2) the function is exposed as a C symbol with the invocation completely resolved at compile time and you receive non-native types of unknown representations (i.e.: a Int, but it could be p6object or p5SV) by using a low-level calling convention (i.e.: no capture object). This already requires your generated code to perform calls to those objects in the level3, but this function is still on level 2.

level 3) the function cannot be completely resolved at compile time to a C symbol, so you need to perform the entire high-level dispatch by first retrieving the function from the object (using .^can) and then calling the function (using the equivalent of .postcircumfix:), but you only use the known representation for the Capture object.

level 4) same as level 3, but the Capture object may have a unknown representation.

The exposure of C symbols can use some sort of name-mangling the same way C++ does so that it encodes the presumed information in each level.

As I said, I have been thinking about this for a while. I hope it is usefull…

Also, I don’t like the look of if/else-if structures in most (if not all) languages when they grow past a few else-ifs. I also think given/when statements are much better when comparing a variable to many different possible values.

I deleted your other subsequent comment because it took parts of statements out of context for the express reason of insulting me, which is what I think you came here to do.

(Finally, I don’t believe your email address is some@where.com)

So I searched for a new language.”

Good grief but that’s inept. A good editor with edit macros eliminates repetitive typing.