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!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4