A vision for Parrot

[Benjamin Goldberg]

Donal K. Fellows wrote:
> 
> Daniel Pfeiffer wrote:
> > 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.
> >
> > 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.
> 
> A common bytecode that Perl, Python, Ruby and Tcl would all compile
> to?  Hmm. Scary, and for several reasons.  Firstly, I'm not at all
> convinced that the object models are compatible enough.

If you were writing a VM for one language, and then tried to extend it
for the others, then I would agree wholeheartedly.  However, it's no
more strange than using MSIL for C++ and VB and other languages.

> And secondly, how are you going to avoid requiring a resident
> interpreter/compiler to handle the case where you've got
> dynamic code coming from a source that doesn't generate parrot
> bytecodes directly (e.g. a normal programmer^Wperson!)

In all cases that I can think of, your dynamic code is essentially a
string which gets eval()ed (with a language-dependent eval).  The
solution is to make the eval() function/operator compile into a sequence
of operations along the lines of: Load the compiler for this language,
(if it's not already loaded), pass that string to the compiler, run the
generated bytecode.

> After that, there's worrying about security models to do as well.  ;^)
> 
> One way forward, at least with Tcl, would be to implement a Tcl
> interpreter in terms of parrot bytecodes (rather like Jacl is a Tcl
> interp written in Java)

Considering that Jcl and Jython exist, it seems like a reasonable goal
would be to make an interpreter which turns Java's .class files into
Parrot .pasm files.  Once that tool exists, one could simply translate
Jcl and Jython into parrot... there would be no need to re-implement
them.

And one day, in the distant future, there will be a Perl6 decompiler,
which will turn Parrot bytecode into Perl6.  Then we'll be able to
convert the translated Jython and Jcl into Perl6 :)

> but that tends to bring out questions like "why bother?"  Could it be
> done without requiring a chunky auxiliary C library to provide little
> things like cross-platform select() support?

No matter *what* language you're using, some sort of interface to select
or poll will be needed, and that interface would be implemented in C.

Whether it's "chunky" or not depends on how that interface appears on
the high-level end of things.

> This sort of thing tends to make me suspicious that this is little
> more than a pipe-dream, well, at least as far as Tcl's concerned.  (I
> don't know the other languages nearly well enough to comment in a
> useful way.)
> 
> Alternatively, formulate Parrot as a sort-of disjoint union of the
> bytecodes used in each language, so unifying them without unifying
> anything.  >:^D

The set of bytecodes which Parrot will be using has been decided, and
while it's not fixed in stone, it's quite unlikely to get a whole other
language's bytecodes added to it.

Assuming you thouroughly understand Tcl's bytecodes, why not take a look
at Parrot, and see whether the set of bytecodes that parrot supports is
sufficient to do everything that Tcl's bytecodes do?

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