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