A vision for Parrot

[Andrew Dalke]

Frodo Morris wrote:
> Benjamin Goldberg wrote:
  ...
>> What advantage would this have over putting a #! line in the bytecode?
>>
> Faster, better, cheaper.
> Imagine if parrot could understand all interpreted code.  Why not leave 
> it running, so that any Perl/Python/Tcl/Ruby/Java/sh/BASIC/whatever code 
> can get to it immediately?

Some years back, RMS proposed a standard 'scripting' language called
Guile.  See, various languages like Tcl, Perl, Python, etc. were
being developed and none of them were 1) developed under the FSF nor
2) a variation of Scheme.  (A simplified and perhaps biased
interpretation of mine.)

A key part of his proposal was that Guile would support translators
from other languages, like Python, C, etc., to Guile.

It didn't happen.  Writing those translators are hard because each
of the languages has different object models, which must be implemented
nearly perfectly.  Guile is a full-fledge language built on years of
research into Lisp and scheme, so I would be surprised if it was any
easier to implement in Parrot's byte code.  It didn't happen with
Guile, it's even less likely to happen with Parrot.

I can "imagine if parrot ..."  But it isn't going to happen without
*huge* amounts of work; comparable to writing Jython.  (A Python
implementation written on top of Java rather than C.)

On the other hand, consider the gcc suite of tools.  These convert C,
C++, Pascal, Fortran, Objective C, ... into a more generic form.  So
there is some known success in doing this.  But I've looked at gcc
code and it isn't something I want to hack, while I've contributed code
to Python's C implementation.

					Andrew
					dalke at dalkescientific.com