Parrot - the way

Posted Mar 26, 2004 0:28 UTC (Fri) by hinoue (guest, #6949) [Link]

The operative word is "WILL". Parrot is very far from being finished and has yet to prove that it is going to replace the current Perl/Python/Ruby VMs. However, you are right that the fight over languages and libraries is a bit silly -- the fight should be over the VM.

The VM ultimately chosen should be decent target for any language. This precludes using a Java VM, IMO. CLR allows for a larger set of languages, but still isn't infinitely flexible. It has the advantage that the runtime is probably unencumbered by IP issues. The .NET libraries are a different story, but presumably people writing applications for GNOME will using GNOME bindings.

However, what is actually needed is really a subset of a VM - a portable intermediate representation along with a well-defined runtime model. This is not an new idea -- I recall that GCC people tried something similar a long time ago. It is an idea that is gaining ground among VM people today, though. VMs on modern systems are no longer seen an interpreters -- good VMs compile code, and the instruction sets of Java, CLR, and even Parrot aren't really great representations to do the kind of analysis for optimization that you would want. (Incidentally, there's only a tiny advantage in using a register based instruction set over a stack one. You've got to put the values in real registers at some point). Redefining the problem to this allows one to dismiss language support and library issues. It would also allow greater amount of modularity -- compilers would then be naturally split between the front end, which target the IR, and the backends, which target the native machines.

Unfortunately, I know of no suitable portable IR, so we are stuck with things that already exist -- Java or Mono.