On Mon, 30 Jul 2001, "Eric S. Raymond" <esr@thyrsus.com> wrote: > 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? This solution sounds like just taking two VM interpreters and forcing them together by having the first byte of the instruction be "Python opcode" or "Perl opcode". You get none of the wins you were aiming for. > I can see one: garbage collection. How is GC a problem? Python never promised a specific GC mechanism, so as long as you have something which collects garbage, Python is fine. -- gpg --keyserver keyserver.pgp.com --recv-keys 46D01BD6 54C4E1FE Secure (inaccessible): 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6 Insecure (accessible): C5A5 A8FA CA39 AB03 10B8 F116 1713 1BCF 54C4 E1FE Learn Python! http://www.ibiblio.org/obp/thinkCSpy
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