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.  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!)  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) 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?  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

Donal.
-- 
Donal K. Fellows   http://www.cs.man.ac.uk/~fellowsd/   donal.fellows / man.ac.uk
-- OK, there is the MFC, but it only makes the chaos object orientated.
                                        -- Thomas Nellessen <nellessen / gmx.de>