A vision for Parrot

[Benjamin Goldberg]

Daniel Pfeiffer wrote:
> 
> Hi,
> 
> this morning it struck me that it would be nice to have Parrot not
> only run Perl 6 and similar byte code, but that any of the common
> interpreted languages be compiled to this same byte code.

Only just this morning?  I take it that parrot itself only came to your
attention recently, since that concept has been with the VM since it's
inception.

> Then no matter whether running a Perl 6, Python, Ruby, Tcl maybe even
> bash script the same interpreter library would be used.  Then likely
> it would already be in memory speeding up start time.

The difficult task is compiling those languages into parrot bytecode.

This may not be horrible if those languages have their own bytecode,
which can then be translated into parrot bytecode.  As an example, there
already exists a perl script which translates java .class files into
parrot bytecode.

For other languages, a compiler would actually be needed -- eg, for
bash.

> And this would also ease cross language module/library inclusion. 
> Imagine instantiating some Python class from Perl!

Ya mean the same way that you can, using Jython, instantiate Python
classes from Java and vice-versa? :)

> Apache would essentially have a mod_parrot.

Well, obviously it would.

> Maybe, if this can be tested very hard, we'd even have a Parrot kernel
> module for all Unices supporting that.  Then exec() could perform
> compiled scripts right away, like machine code :-)

Or, your whatever_2_parrot compiler insert an appropriate #! line at the
beginning, pointing to the parrot VM -- this is much simpler, as it
takes advantage of an existing mechanism.

-- 
my $n = 2; print +(split //, 'e,4c3H r ktulrnsJ2tPaeh'
."\n1oa! er")[map $n = ($n * 24 + 30) % 31, (42) x 26]