A vision for Parrot

[A.M. Kuchling]

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.

Bridging data types across languages allows the NxM specter to
reappear.  What does PerlString "2" + PythonInt 1 do?  Who decides?
When someone writes RubyInt and RubyString (assuming Ruby's strings
aren't identical to Perl's), do the PythonString and PerlString
maintainers need to add support for them?

Perl's strings are mutable and Python's aren't; do we need to copy all
the string parameters whenever Python code calls Perl code?  Or will
it work as long as the Perl code doesn't trying modifying a string?
So much for seamless cross-language calls, then.

Even for the more limited world of Python extensions, it's hard to
ensure that data types interoperate as much as possible.  For the
wider, weirder world of "all datatypes for all scripting languages",
arranging sensible conversions will be even more difficult.

--amk                                                             (www.amk.ca)
PROSPERO: A turn or two I'll walk, 
 To still my beating mind.
      -- _The Tempest_, IV, i