(with the languages Nice and Groovy) and .net, but written esecialy for scripting-languages.
True, Parrot is slanted toward dynamic scripting languages that recompile and eval themselves
on the fly, but it does provide low-level registers and features that nice, statically bound languages
without continuation passing style can call.
I've already done this with a demo Java like language that only uses the low level numeric and
string registers and uses the faster jump/bsr instructions rather than the continuation passing style.
If you read my IMCC faq, you'll also see how I kludged OOP without using Parrot's dynamic
class support. It results in very fast code that is well-JITable, compared to what Perl6 compiles to.
Point is: You can do it how you want to, but if you want to cooperate with other languages on
the Parrot VM, you'll need to use the Parrot conventions at least on the boundaries of your
modules.
But I see two problems:
1. the license
Perl is licensed under the GPL and Artistic license. Python is licensed under the Python-license and Ruby is licensed under the GPL and its own license.
So, it would be nice, if Parrot would be licensed under the GPL, Artistic license, Python-license and Rubys own license.
I don't think, that Python would be public its package with something included, which is under an other license then the Python-license.
Moot. You can write commercial compilers that target the Parrot VM and distribute it as you see fit. On top of that,
if you don't use anything but what Parrot provides in its base PMC classes, you don't even have to distribute a
runtime lib for your special language.
2. Parrot is written by Perl-people for Perl
I think it would be better, if there existing a group of 2 Perl people, 2 Python people and 2 Ruby people or so, which disigned _together_ a VM for scripting languages and then support all this VM.
The VM is designed and working, the VM boys have done the bulk of their job. Parrot can currently
do things that the JVM cannot. Parrot's support library needs a lot of work, but this has
never stopped compiler writers in the past. :)
It is time for the compiler writers to start pulling the load.
I have red, that you create yourself a Python for Parrot. But that wille be not more supported by the Python-people like IronPython or Jython I think. It would be better to working with the Python and Ruby people together. And letting Parrot independent of any language.
Perl is probably the heaviest influence in the scripting world. I'd wait and watch what happens when Perl6
is for real and we start doing releases for the Parrot VM and see how many people follow.
-Melvin
