A vision for Parrot

[Steven D. Arnold]

On 11/6/02 3:21 PM, "A.M. Kuchling" <akuchlin at ute.mems-exchange.org> wrote:

> In article <mailman.1036579568.14685.python-list at python.org>,
> Carel Fellinger wrote:
>> Ofcourse for parrot this isn't a show stopper per see, as parrot
>> doesn't have to translate into each of the supported languages, it
>> just has to understand them.  But still, parrot will have to support
>> all the dark corners of all supported languages, quite a mess me thinks.
> 
> Parrot will still have an NxM problem with datatypes.  Parrot supports
> datatypes through PMCs, which are basically arrays of C functions
> equivalent to PyObject, so you'd have a PerlInt, PerlString,
> PythonInt, PythonString, etc.  Different PMCs would have different
> results for various operations, so PerlInt 1 + PerlString "2" == 3,
> while PythonInt 1 + PythonString "2" raises TypeError.

There may be difficulties like the ones you bring up, but my feeling is the
Parrot people ought to go for solving the easy 90 percent of the problem,
even if it means that little code from any language will work out of the box
(except perhaps perl6; it is their baby, after all).  Another approach is to
get great interoperability with the top three or four languages, like Perl6,
Python and Ruby, and do the rest later if there is interest.  IMO, if
authors have to rewrite a few percent of their code to interoperate with
Parrot, and the benefit is we can start using it in a year instead of three,
that's a deal I'd take any day of the week.  Perfectionism is the enemy of a
project like Parrot.

It seems to me that there should be little problem getting Python or any
other language to function well in Parrot, especially if the Parrot people
try to make this easy as I imagine they would.  Indeed, it should be no more
difficult than getting the same languages to work in machine language, which
has obviously been done.

The problem arises when the APIs that are used to facilitate communications
between Parrot programs do not support semantics in a given language.  Here
we have the hard problem of choosing between great flexibility and great
performance.  It seems like an ideally-written Parrot would give each
program the ability to define its own semantics, and then other programs
could choose to be compatible or not.  For example, my program could conform
with protocol X, and if you support protocol X, you can use my program, call
its functions etc.  You and I both know what to expect.  The key with Parrot
is that it must expect the unexpected -- it doesn't know what people will
want to do with it in the future and so it should try to avoid arbitrary
limits.

With that done, the languages will have to evolve some to work with Parrot.
For example, Python will need to have a way to understand that it is calling
a function or creating an object that uses Perl6 semantics and it will need
to not expect that object to behave exactly as would a Python object.
Languages could also try to provide a protocol bridge so that an object
using Perl6 semantics looks and feels just like a Python-compliant object,
but again IMO the Parrot people should narrow their focus and let other
people do this.

Note that I have never written a compiler and I'm therefore substantially
less knowledgeable about this issue than many on this list.  Corrections, as
always, are welcome.

steve
--