You can clone with
Cannot retrieve contributors at this time
We need some kind of overlay language for M0 that we can use to reimplementParrot. Writing poke_caller was hard and writing a factorial program will beharder. Anything less trivial will require an actual compiler or codegenerator. We have the following options: 1 (PIR/M0) emit M0 from PIR 2 (nqp/M0) emit M0 from nqp 3 (winxed/M0) emit M0 from winxed 4 (new-nqp/M0) write a new compiler targeting M0 using nqp 5 (new-custom/M0) write a new compiler targeting M0 using a separate toolchain 6 (steal/retarget) take someone's existing compiler, retarget it to M0PIR/M0 has the advantage that we'll need to do something similar later anyway.Being able to translate from PIR to M0 will be necessary if we want to continueto support PIR, and we do. I'm not sure if we'll want to replace Parrot'scurrent C code with PIR, though. This approach is worth considering.I don't like the idea of nqp/M0. nqp is already quite slow and I don't see itbeing feasible to get a speed improvement by using it more internally. Itmight be the case that we don't need to generate inefficient code to deal withlvalue semantics if the translation is well-designed. There's also the concernthat using nqp almost universally means using a bunch of pir:: garbage, whichwould make M0 translation less efficient. Overall it's a fairly nice language,but I'm not certain that nqp/M0 is the best way forward.winxed/M0 is a nice option. The compiler already exists and has an alternateversion (winxedxx) that targets C++. Unfortunately winxed isn't designed tosupport multiple codegen backends, so we'd have to either refactor codegen intoa separate step (probably slowing down performance) or just fork it and write anew backend. The language itself is quite pleasant, but the compiler needswork. I'm still not convinced that this is a bad way forward.new-nqp/M0 brings with it the speed issues of nqp. nqp is very much designedto support a highly flexible compilation workflow, so using it to generate M0is a reasonable approach. I'm not a fan of the langauge's speed and quirks,though. This approach could be made to work but it doesn't sound like the bestapproach.new-custom/M0 is almost included for the sake of completeness. I'm tired ofwriting meta-things and want to get some real work done. Writing a newcompiler from scratch is decidedly non-lazy.steal/retarget is a generalization of the winxed/M0 approach. Instead ofretargeting winxed, we'd take an unrelated compiler for some language (js comesto mind) and target that at M0 using CPS for control flow. This has theadvantage that we're not writing (and debugging) a whole new compiler fromscratch, but it depends on us finding an appropriately-licensed compiler for asuitable language and constructed in a modular fashion.