Guido van Rossum <guido@zope.com>:
> Or just download 2.2a1.
It's cool. My local installation is from 2.2.a0. I'll update.
> > And...um...why? Has the bytecode changed significantly recently?
>
> Not the bytecode, but the rest of the runtime has changed
> tremendously, and as I tried to explain over the phone, that has a big
> impact on reusability of the runtime. The bytecode engine cannot be
> considered independent from the rest of the runtime.
OK, let's try to factor this design problem.
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.
(Note: making the type ontologies of the two bytecodes match is not
the same problem as making the type ontologies of the *languages*
match up. It should be rather simpler because a lot of the
differences between, e.g., class semantics can probably be compiled
away. Not a trivial problem, but humor me.)
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?
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
An armed society is a polite society. Manners are good when one
may have to back up his acts with his life.
-- Robert A. Heinlein, "Beyond This Horizon", 1942
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