[Python-Dev] Parrot -- should life imitate satire?

[Thomas Wouters]

On Mon, Jul 30, 2001 at 05:18:31AM -0400, Eric S. Raymond wrote:

> Let's suppose, for the sake of the design discussion, that we can make
> the type ontologies of the Perl and Python bytecode match up.  

I'm afraid I'll have to side with Jeremy when I say, "What?"

> Let's further suppose that we have a callout mechanism from the Parrot 
> interpreter core to the Perl or Python runtime's C level that can pass out 
> Python/Perl types and return them.

> Given these two premises, what other problems are there?

> I can see one: garbage collection.  What others are there?

As a midnight braindump:

What about Perl's 'dynamic' (or 'really JIT') compilation ? The incessant
weak typing -- would this be part of the Perl side of Parrot, or part of the
Parrot types ? The differences in the regex engine; in Python, regular
expressions are optional. Also, the Perl engine has some features SRE
hasn't, yet, and vice versa (last I checked, Perl's regexps didn't do
unicode or named groups.) And what about Perl's 'Taint' mode ? I don't see
how you can emulate that ontop of the Parrot runtime, as it's a tag that
gets carried into operations. And I won't even start with Perl's more
archaic features, that change the whole working of the interpreter.

You mentioned regular expressions as an upside for Python, from this
'merger'. Why is that ? We have a good regex engine, and it's tuned to
Python's needs. Do we need 'regex literals' ? Why ? And why would we need a
merger with Perl for that, anyway -- I've seen some arbitrary-type-literals
suggestions come by in the last couple of days that would make it
possible :-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!